引言

众所周知微服务已经经过了炒作周期的兴奋阶段，但并不是说它现在过时了。微服务架构算是笔者过往印象比较深的项目之一。并且，即使作为行业的最佳实践，但也能看到各种各样失败的案例。所以今天想跟大家分享一下关于微服务相关深度思考的话题。

微服务这个话题已经被讨论的太多太多，但笔者还是想以现在 Web 应用设计的经验出发，发表一些与众不同的观点。

单体与微服务

首先，单体系统和微服务的区别，在这就不多说了，因为太基础了，懂得都懂。那么，为什么要用微服务呢？业界对单体系统和微服务的普遍观点是：单体系统非常容易开发、测试、部署，但是单体系统面对的问题也很多，例如开发效率变低、维护成本增加、部署影响变大、可扩展性较差、技术选型成本高，而引入了微服务可以实现每个微服务易于开发与维护，便于沟通与协作，很适合小团队敏捷开发与持续交付；每个微服务职责单一，高内聚、低耦合。同时，每个微服务能够独立开发、独立运行、独立部署；每个微服务之间是独立的，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响；每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水平扩展与垂直扩展；每个微服务可以使用不同的编程语言以及不同的存储技术，使得我们更容易尝试新的技术。

简单与复杂

其次，微服务是个大染缸：单体系统让很多人诟病的是其服务内聚混乱，看起来就像一个球。那么，服务化之后，就解决了这个问题了吗？事实上，微服务通过拆分单体系统使其成为多个体积更小的服务来降低单个服务的复杂性，让单个系统看起来更加的职能清晰，但是，整个系统架构变得更加复杂。

微服务的数据

接着，微服务中的数据是如何独立的：微服务的一个主流观点是，在每个服务都有自己的缓存和数据库，并且缓存和数据库是相互独立且透明的。因此，共享缓存与共享数据库是不对的。那如果服务 A 需要获取服务 B 的数据怎么办？一般的做法是，服务 B 提供一个获取该数据的 API 接口，而服务 A 通过调用该接口进行业务组装。因此，微服务化之后，服务之间的数据交换都是通过接口来开展的，如果服务 A 越过服务 B 的业务逻辑之间访问服务 B 的数据，其会破坏了微服务之间的数据独立性。

团队协作

然后，微服务如何进行团队协作：微服务对与组织结构提出了新的要求，它建议将大团队拆分成为多个小团队，而每个团队各自运维开发和运维一个或多个服务，并且需要流程上持续交付、持续部署、DevOps。

不同的服务可能由不同的团队开发与维护，实际场景下，微服务的便利性更多的在于团队内部能够产生闭环，换句话说，团队内部可以易于开发与维护，便于沟通与协作，但是对于外部团队就存在很大的沟通成本与协作成本。如图所示，团队 A 对于服务 C 的了解是一个黑盒，我们不知道它是单体服务还是微服务，它部署了几台服务器，需要依赖哪些下游服务，是否存在限流、熔断和降级策略，以及如何接入。如果我们需要确认这些问题，通常情况下，都需要人工协作和确认。

适合场景分析

最后，微服务架构适用场景分析。

在实际开发中，需要考虑多种因素，来决定采取哪种架构模式才适合当前业务发展情况。

毕竟微服务也不能“包治百病”，不要把它当做万能药。企业研发哪里得病了，觉得只要把“微服务”这服药给用上，就药到病除。哪有这么简单的事情。微服务有它自身的特点，优点和缺点，有其适用范围，微服务并不能解决所有问题。你需要综合考虑一些情况。

比如 业务所处发展阶段：

• 刚开始探索

• 高速发展期

• 还是成熟期

业务的复杂度：

• 业务访问量是多还是少

• 用户量是多还是少

开发人员：

• 开发人员素质，是初级还是高级

• 开发人员的数量

产品的形态：

• APP

• web

• 小程序

是否 3 者都有，等等都是需要综合考虑的因素。