软件开发人员从0到1实现物联网项目：项目架构的思考

前言

因为种种原因，《软件开发人员从0到1实现物联网项目》这个项目的进度停滞了将近一个月。

鉴于该项目的前期开发和后期的维护就我一人，为避免开发效率低下和后期维护中的潜在问题。我针对项目架构进行了初步的思考，从开发模式到后期维护进行了全面的梳理。基于这些思考，最后整理出了一份简单的技术架构图。有什么不足之处还请各位大佬不吝赐教，欢迎提出宝贵的意见和建议。

前两年的市场绝对是微服务的天下，开发个什么系统，动不动就是微服务，几乎已经成为每个项目的标配。

在我看来，微服务只适合业务规模大、团队规模庞大的项目。主要是一个大项目在单体应用下确实会存在很多问题，就像2007年的淘宝网一样：

整个淘宝网是一个几百兆字节的WAR包，大大小小的功能模块超过200个。几百人维护一个WAR包就会带来很多问题：

每一次的功能升级都要牵一发而动全身，这种情况下就不得不拆分系统。

自助棋牌室系统或者说是无人看守门店系统，一个小小的项目，功能并不多。所以，单体架构，足矣。否则，带来的只有繁琐的开发部署流程以及高昂的运维成本。

本项目的用户终端主要包含微信小程序和后台管理Web端。其中小程序服务于用户和商家，Web端则为商家和后期维护人员提供管理工作。

App一开始就没在考虑范围。（ App 下载门槛高，打开率低）

在小程序与后端服务的交互方式，我决定使用云调用，主要是为了简化代码开发流程和规避不必要的风险。

以登录功能为例，使用传统的微信对接方式，需要涉及复杂的步骤。如下图

虽然有很多SDK可以简化和微信平台的对接流程，但还是消除不了相关的工作和潜在的风险。毕竟，每增加一个处理环节，都可能会增加潜在的风险。

而在小程序端如果通过云调用向云托管服务发起请求时，后端服务会在header中获得该请求用户的全部信息，比如openid、unionid等。上图的 wx.login 获取code置换登录的流程就没有存在的必要了，也不用维护再微信接口调用凭据、token。

虽说是单体应用，但也是可以具备高可用、高并发能力的。除了程序自身的性能外，还需引入很多机制来辅助。例如实施负载均衡、实现数据库的读写分离以及确保应用实例的弹性扩缩容等。

但是，这些机制的引入会消耗自身的一些精力，尤其是后期复杂的维护工作。鉴于该系统后期的维护就我一人，为了降低维护成本果断上“云”。

在了解小程序开发期间，我发现了云开发和云托管这两个强大的工具。如果说云开发是专为小程序开发量身打造的，那在我看来，云托管可以算是真正的“云”了。

简单来讲，云托管就是：把你的程序交给云管理，免去人工运维。

云托管的免运维具体体现在以下几点：

自带功能：云托管自带监控告警、日志服务等后期运维所需功能。
（实现哪个功能不需要工作量？）
自动扩缩容：根据流量多少和自身承载消耗动态的进行扩缩容，从而保证服务高可用、高稳定，也无需为闲置资源付费。
（既不用自己管理计算节点又可以避免额外的资源成本，而且，高可用和高并发是不是解决了？）
DevOps自动化：提供流水线能力，可以实现从代码仓库到服务发布的全自动流程。还提供灰度发布、版本回滚这样的部署能力。
（不用自己打包部署或者自己搭建DevOps环境）

就是说，单单这三点能为我省去多少工作量。如果应用部署到云服务器上，哪一个工作量不够我喝上一壶？我还用担心半夜的服务监控告警吗？

当然，云托管不只是对应用程序的托管，还提供了Serverless形态的Mysql，也可自动扩缩容，避免产生瓶颈。
（又省了Mysql的运维工作）

不过，这都不是重点，重点是云托管还提供了免费的CDN和DDoS防护。