质疑微服务设计

这套分布式微服务体系建设到现在，已经有半年以上了。前段时间因为技术顾问和项目经理的一些提问，我有些质疑我的设计是不是合理的。

这里以我的Blog系统为例进行说明，博客系统基础构架为如下:

• 用户模块；
• 文章模块；
• 评论模块。

结合我的微服务设计最终为演变为如下:

• 用户微服务；
• 文章微服务；
• 评论微服务；
• 服务注册中心；
• 网关微服务；
• 统一认证微服务。

看似只有六个，实际有十二个微服务。因为其中用户微服务包含用户数据存取微服务、用户业务逻辑处理微服务、用户接口微服务，文章微服务、评论微服务同理。

按照当初技术顾问的设想，每个人的职责不一样，设计数据库的专门写数据存取微服务(即DAO微服务)，具体逻辑组装的由开发人员实现，也就是开发人员不一定懂业务(这里的不一定懂业务，指的是业务了解不深，而不是什么都不懂)，只负责数据组装即可，其实间接也反映了单一职责原则，即每个人只做一件事情。

也就三个功能，涉及了九个微服务，如果还要增加一个问答，肯定要加对应三个微服务，也就是从九个变成十二个了。这样一来只要一加新的功能如找工作、课程、直播等，都会加微服务，随着微服务越来越多，系统也变得越来越复杂，这涉及到微服务如何管理、微服务之间的通信如何保证、微服务部署如何高效快捷、微服务的稳定性、团队之间的沟通(不同的团队负责不同的业务模块等)，微服务的安全性等这些都会增加微服务的复杂性。

但复杂性也可以降低，将复杂变简单，不能马上就变简单，但可以逐渐演化。

目前我的措施如下:

• 微服务如何管理(Eureka或Nacos就能管理，前提是微服务的注册中心必须是其中任意一个，通常来说Nacos会比较友好)，通常微服务的管理还需文档化(编写对应的文档标明每个微服务是做什么的)；
• 微服务之间的通信如何保证(微服务之间的通信基于HTTP协议，通过服务注册中心进行彼此间的服务调用，一般来说，只要服务没有宕机，就能给予正常的响应反馈)；
• 微服务部署如何高效快捷(这个是我一直在推行的，用shell将部署流程脚本化，除了脚本化，我还采取分类化，例如部署文章服务，就执行文章微服务脚本即可，如果是评论微服务，执行评论微服务部署脚本即可，脚本执行成功都会有一个成功反馈，当然了如果是报错也会直接反馈)；
• 微服务的稳定性(所谓稳定性，主要担心服务时不时就宕机，保证稳定性，通常是集群的方式，Eureka和Nacos均支持微服务集群)
• 团队之间的沟通(以博客为例，问答微服务需要用户微服务提供某些API，这就涉及到团队之间的沟通，这个沟通关于问答微服务需要用户微服务提供哪些数据、什么时候提供、以什么形式等，沟通顺利的话还好，但是因为有些时候有一些数据不那么好提供，用户微服务可能需要找其他微服务组要API，这就需要一个主导者负责协调，没有一个主导者，最后的结果会导致微服务越来越难管理、越来越乱，变成一座屎山);
• 微服务的安全性(假设大多是在一台服务器上，对外只开放网关的端口，微服务之间的通信仅仅是基于内网，对于特定的外网，进行具体的IP地址校验和开放，避免非法IP地址进行非法请求，这里不影响服务集群，只需确保服务注册中心集群即可，当然了接口访问肯定是要鉴权的)。

面对质疑，人都会有抵触情绪的，但质疑并不是一件坏事，质疑能在一定程度上有助于你发现设计上的不足，可以针对性优化，同时也能深化你对系统设计上的认识。