Microservice架构模式简介

使用最合适的技术所带来的优点就是，服务的代码会变得非常清晰明了，甚至在有些情况下可以达到简洁优雅的程度。在一些讨论中，有些人甚至建议一个服务只需要10到100行代码（他们常用简写LoC，即Lines of Code）。再加上服务已经独立出来，而不再与其它服务混合在一起，因此正确地使用Microservice架构模式大大提高了代码的维护性以及新人上手的速度，也有助于技术人员在日常工作中进行技术集的更新及转换。

但是这种对于服务的分割和组件之间的分割并不相同。最重要的一点就是在各个服务之间进行通讯的消耗相对于在同一个进程中而言是非常大的。在设计一个组件的时候，我们需要考虑该组件所给出的接口能够尽可能地满足当前及今后的一系列可以预见的需求，这便要求该组件所提供的API具有一定的前向兼容性，并拥有一系列其它特性，如灵活性，扩展性等等。这常常导致该组件所提供的API具有较细的粒度。在程序运行时，对该组件所提供的API的调用就在当前进程中进行，速度非常快，因此频繁地对该细粒度API进行调用并没有太大的问题。但是一个跨服务调用所需要的时间则比进程内调用的时间长很多。如果在处理一个请求的时候需要太多的跨服务调用，那么整个应用的性能将变得无法忍受。因此我们在执行服务分割时定义的API需要是粗粒度的API。

就让我们以一个电子商务网站为例。在为用户生成订单时，电子商务网站常常需要列出各个商品的主要信息，商品的价格，优惠幅度，并通过库存系统检验该商品的库存，从而得到整个订单的内容。如果每次与其它服务沟通都需要100毫秒，而且整个订单包含了20件货物，那么系统准备订单的时间就会达到8秒（100ms * 4次调用 * 20件商品）。这从用户的角度来说是不可以接受的性能。而且随着订单中所包含商品数量的增多，系统准备订单的时间会线性增长，进而使得系统的性能更加不可忍受。

究其原因，实际上还是因为准备订单所调用的API的粒度太细了。如果订单系统能够一次性地把一件商品的主要信息，价格，优惠幅度以及库存信息从商品服务中取回来，那么其效率就将提高四倍。如果订单系统不需要为每件商品依次发送请求，而是可以通过一次性地服务间调用就能取回所有需要的信息，那么系统准备订单的时间将不会再随着订单的增大而增长。因此在Microservice架构模式中，各个服务应该提供可以被灵活使用的粗粒度API，以减少各种跨服务调用的消耗。