首先,我个人观点:微服务有必要性,但不是什么应用都要选择“微服务”。

从微服务解决的问题来看参照各大微服务架构的定义以及模式,对微服务有一个如下模型

微服务模型

如图该模型是一个正方体,分别有y、x、z三个轴向,其中y轴代表的是业务粒度,x代表的是服务的横向扩展,z轴代表的是服务的分区,也就是流量分治。

y轴:业务的粒度决定了服务的高度,我这个服务有什么功能业务边界在哪里

x轴:服务的横向扩展,例如服务的负载均衡

z轴:服务的纵向扩展,例如流量分治,湖南的订单和湖北的订单交由不同分区的横向扩展节点处理

这三根轴,基本包含了一个服务的业务、可用性和吞吐量的衡量。

微服务的前提

  • 新产品前期的评估
  • 单体应用转向微服务

新产品前期的评估

先给结论,个人观点:

  1. 如果你的项目是外包项目,产品周期和维护周期都短且团队规模和产品功能数量不成正比,不要使用微服务,就算团队规模和产品功能数量成正比,也无需使用,因为产品周期短,维护周期短,没有必要,对于单个的功能热点大不了做成分布式单体架构。

  2. 如果你的产品团队规模和产品功能数量不成正比且产品周期长,如果需要前期版本的快速迭代,建议前期先不要使用微服务,但未来产品的架构微服务是比单体架构更好的选择。(见下小节《单体应用转向微服务》)

单体应用转向微服务

当一个单体应用架构意识到该转向微服务架构时,那么我就假设,这个产品的产品周期长且维护周期也长,那么就应该单机立断的转向微服务,没错,这就是一个很不严谨的说法,我还就说了。

单体应用优缺比走向

随着产品周期越来越长,单体架构应用的优点渐渐的开始衰减,缺点,当然维护周期也从来都不是独立存在的也会跟随着产品周期不断的增长维护的代价与时间。

就算整个团队都是训练有素的高品质Engineer,那也仅仅只是延缓了优点衰减的时间而已单一的源代码管理和所有模块之间的耦合导致团队之间沟通成本不断增加,项目代码的体积不断增大导致项目的复杂度不断的增高,项目从之前的开发难度从易到难,缺点的凸显似乎只是迟早的事,随着产品周期越来越长,用户数量也成规模增长,单体应用天生的的故障不隔离问题也逐渐凸显,例如一个功能的内存泄漏将会整体应用的崩溃,总而言之单体应用随着时间的推移反复迭代,单体应用的长期末路就有可能形成一个大泥球。

所以一开始早期采用单体应用架构的项目,在后期有意识到要转向微服务时,请取舍好时机,并不是一定要转向微服务才是项目最好的归宿,业务的拆分和定义也是一项有难度的挑战,同时微服务也需要高度的自动化持续集成,有的时候可能做成分布式单体架构兴许可能也还不错,但无论如何,还有一点特别重要,在转向微服务时,请多多考虑“人性”。

结论

说了这么多,只是为了提供一些该不该微服务的见解,并不是要大家一昧的去选择微服务,只是希望大家能明白该不该微服务,何时微服务,微服务它也不是银弹,再软件工程里从来就没有银弹,也希望大家保持一个中立的态度理性办事,不要在微服务架构和单体架构之间2极分化,2个架构都很好都各有适用的场景不要一昧的去使用谁。