微服务架构
之前谈过微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。
什么时候需要微服务架构
从生产力和系统的复杂性这两个方面来看，公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。
这个时候系统业务量较小，可以直接Java应用程序打包为War包部署在一台服务器上，整体架构如下图所示：
这种将所有功能，都部署在一个web容器中运行的系统，就叫做单体架构，也叫巨石型应用。
单体应用的优点在于：单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
随着公司的发展，业务复杂性慢慢提高，以及访问量越来越大，会出现如下情况：
- 编译时间过长;
- 回归测试周期过长;
- 开发效率降低，因为所有业务都混在一起；
- 团队扩展了，需要分工明确了，按照业务来发展，大家都高效；
这时候就可以采用微服务来提升生产力了，至于这个转化的点，需要团队的架构师来进行各方面衡量，就个人经验而言，团队发展到百人以上，采用微服务就很有必要了。
有些架构师是具有微服务架构能力，所以设计系统时就直接设计成了微服务，而不是通过单服务慢慢演化发展成微服务。
下面我谈谈微服务架构演变过程中的5种设计模式。
聚合设计模式
为了尽量减少服务之间的通信，我们可以使用服务聚合模式。
基本上服务聚合设计模式，是接收来自客户端或 API 网关的请求，然后分配给内部多个后端微服务，再将结果合并，并在一个响应结构中发给请求发起人。
如下图左侧所示：
代理设计模式
在微服务架构中代理服务是必然存在的，常用的代理服务是网关服务。
微服务的各个服务是没有状态的，需要通过统一的入口：代理服务，经过权限的校验、请求的过滤，比如：非法请求、SQL注入等。
最后再请求具体的服务，如下图左侧所示：
异步消息传递设计模式
如果通信只是在少数几个微服务之间进行，那么同步通信就很好,但当涉及到多个微服务相互调用，并且要等待一些长时间的操作完成时，我们应该使用异步通信。
虽然REST设计模式非常流行，但它是同步的会造成阻塞，因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。
如下图所示：
链式设计模式
单个服务或者微服务将会有多级依赖，举个例子：Sale 的微服务依赖 Product 微服务和 Order 微服务。
在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。
所有服务都使用同步消息传递，在整个链式调用完成之前，客户端会一直阻塞，因此，服务调用链不宜过长，以免客户端长时间等待。
数据共享设计模式
我们已经说过，在微服务里，为每个服务分配一套单独的数据库是理想方案。
采用共享数据库在微服务里属于反模式，但是，如果应用程序是一个单体应用而且试图拆分成微服务，那么反正规化就不那么容易了。
在后面的阶段里，我们可以转到每个服务一套数据库的模式，直到我们完全做到了这一点。
但在重构现有的单体应用时，SQL数据库反规范化可能会导致数据重复和不一致。
因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式。
如下图所示：
在这种情况下，部分微服务可能会共享缓存和数据库存储。
不过，这只有在两个服务之间存在强耦合关系时才可以，对于基于微服务的新建应用程序而言，这是一种反模式。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》