引言

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

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

单体与微服务

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

简单与复杂

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

微服务的数据

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

团队协作

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

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