质疑微服务设计

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

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

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

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

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

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

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

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

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

目前我的措施如下:

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

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

文章目录