微服务架构真的不适用了吗

最近，微服务架构在国产化的潮流下，出现了一些不同声音。在私有化的情况下，微服务反而会带来非常大的困扰。比如原来单体架构，很容易部署的场景，现在变得复杂了，以前实施人员一键搞定上线，现在专业运维人员努力才能搞定，成本、时间、质量、运维都带来了非常大挑战。

于是乎微服务架构无用论时有抬头，不对，严格来说是不适用论，不管哪种论调，感觉都有点矫枉过正。

来看一下微服务架构之前的核心主流架构，即单体架构。在之前参与ToB的ERP时代是典型的这种架构，一套代码，所有开发人员进行需求开发、BUG修改、集中发布，对应的可能是几个月产品更新。安装包制作好后，做好安装盘，一线人员直接在客户机房进行安装部署上线。研发团队做好Dev的开发工作，一线承接后续Ops，Dev和Ops大部分情况下是分离的，运维可能会比较少或客户自己搞定或者购买运维服务确保系统的稳定运行。那时版本不更新是常态，只有客户需要进行个性化调整才会进行系统更新发布。

基于这些应用特征，单体架构最大的优势是易于开发和部署，在非海量数据或请求下，可以调出最优的性能。但是由于是一套代码，耦合度相当高，即使是非常注重解耦的团队，也无法真正做到，只会是一厢情愿。同时多个团队在一起开发，发布周期一般以月为单位甚至更长，产品的进化速度受到了大大的制约。

当然在面对私有化客户时，单体架构具备非常大的优势，但在产品的进化，敏捷维度则显的力不从心。这也是为什么微服务架构在私有化时代受到挑战的一个重要原因。

那既然有这么多好处，是否为了私有化就要将已经服务化的产品，重新调整回到单体架构呢，这个是完全没有必要的。

让我们看看微服务架构，面向ToC产品形态，快速演进、快速迭代必不可少，微服务架构完美的给予了支撑，也是为此应运而生的。

面对单体架构的技术问题，开发人员的技术负载太大，随着时间的推移，慢慢系统改不动不敢改成为了常态，重构后质量控制好的可能会好一阵，质量控制不好的可能立马陷入另一个质量漩涡，这样的例子还是比较多的。由于发版比较慢，用户体验是一个非常大的挑战，出现问题也无法快速得到解决。

对于单体架构的人员问题，比较明显的是组织受康威定律的影响，会极大影响产品架构，在单体架构时代会有整体的设计，人员的沟通也会比较顺畅，但是集中在一个环境资源的抢占非常大，等待的现象时有发生，比如发布可能一个团队的一个问题导致所有产品的发布失败，这个问题是一直被诟病的。

微服务架构比较好的解决了上述2类问题，也是微服务的优势，比如说：

1）组织拆成比较小，服务边界比较明确，服务接口也比较清晰。

2）按照服务边界的划分敏捷团队，进行迭代式开发，快速演进和迭代，促进了产品的进化。

3）客户能享受不断迭代享受到产品新的特性以更好的支撑起业务场景，特别是可以享受行业KnowHow应用实践。

4）发布过程并行化，各敏捷团队相互不影响，提升DevOps的效能，提升整体研发效能。大家可以脑补一下500人以上的研发团队分别进行单体和微服务发布的便利性的差异。

5）分布式架构，灵活的扩容，支撑大数据量海量请求的性能和高可用，这个是最大的能力。

6）不同服务可以用不同语言，可以支撑多语言、多框架。

总之敏捷、效率、弹性、收益是微服务架构一些特性，以支撑起更大规模研发团队的开发工作。

当然微架构也有非常明显的问题：

首先是部署成本，由于采取了分布式、云原生部署方式，部署成本高，相比单体架构是2~3倍的逻辑。

其次是运维成本的增大，由于云原生组件非常多，对于运维的能力要求高，运维监控也比较大的要求。

最后是团队的协作，由于边界非常清晰，大家的边界感也非常强，出现问题排查协作非常多，处理速度降低。

单体架构和微服务架构都有非常明显优劣势，各自都有相应的适用场景。

面对当前国产私有化的浪潮，微服务架构关于部署方面的劣势需要尽量收敛，解决办法可能是保持合适大小的微服务，即服务模块化，这样即能保持微服务的一些优势，也有单体快速交付的优势，融合优势，即满足客户要求，又能保持比较好的开发效能效率。