微服务, 顾名思义，是一些小而自治的服务.

小

随着新功能的开发, 代码会越来越大, 为了系统的稳定和可维护, 在单块应用中, 常常会进行模块化等拆分过程，分而治之, 然而这些模块的界限很难确定.
而划分模块时，比较常用的是单一责任原则, 其中 Robert C. Martin 对 Single Responsibility Principle 有这样的论述: 把因相同原因的而变化的东西聚合在一起, 而把因不同原因而变化的东西分离开来. 如果将这个原则应用到分布式系统的服务划分, 同样的原理, 让一个服务拆分到足够小, 使其专注其边界内的事, 就能够避免很多代码库或单块应用过大衍生的问题.

自治

自治性, 其实是跟耦合相关联的. 也即是说, 如果一个服务和客户端耦合过多, 客户端相当于过多参与服务内部的流程, 影响了服务的自治性.
而服务是通过 API 进行通信, 那么 API 的设计就要选择与具体技术不相关的 API 实现方式, 避免耦合.
如何判断一个服务有没有很好的解耦, 可以思考一个问题, 我这个服务能不能很方便的修改和部署, 而不影响其他所有服务.

微服务有什么好处?

那么，微服务能给我们带来什么好处呢？

技术异构性

首先，前面介绍自治性时提到，我们要选择与具体技术不相关的 API 实现方式，因此，微服务可以让我们为不同部分的业务和功能选择最合适的技术.

弹性

在单块应用中, 某项功能故障很可能导致整体的不可用. 但微服务可以很好的处理服务故障和降级的问题.

拓展

一个大型单块应用只能作为一个整体拓展, 而微服务可以很容易的对某些部分进行拓展.

简化部署

单块应用需要整体部署, 就算修改了一行代码, 这也导致单块应用的发布周期是比较长的.

组织结构

小而专注的服务, 可以让对应的团队同样小而专注, 使工作和交付更加高效.

可组合性

微服务架构可以更好的重用已有服务, 并组合这些服务可以实现不同的应用.

对可替代性的优化

有时候想要重新实现或替换某个服务, 比起单块应用来说, 可操作和安全性更强.

其他分解技术

前面提到了很多单块应用的缺点, 有童鞋可能会问, 其实单块应用也有相应的技术去分解系统. 比如共享库 / 模块等.

共享库

首先说一下 共享库. 一个服务可以做成一个共享库来提供功能, 但是这种方式有一些缺点.
首先, 无法选择异构技术;
其次, 会失去对系统某部分进行独立拓展的能力.
还有一点, 如果对某个库进行了更新, 那么可能要重新部署依赖这个库的系统(除了动态链接库), 更严重的是无法保证架构的安全性和弹性.

模块

Java 中有一种叫 OSGi 的模块技术, 可以在不停止进程的情况下, 对模块进行更新. 但它的复杂性要远大于带来的好处, 而且依然会限制我们使用新技术和进行独立拓展的能力. 不可否认，在单块进程中创建隔离性很好的模块是有可能的，但是很难做到，因为模块很容易和代码耦合在一起。

没有免费的午餐

说了这么多微服务的优点, 当然天下没有免费的午餐, 当选择了微服务, 你还需要面对许多分布式下的问题( CAP / 事务等). 而且微服务是否适合你, 还需要结合业务场景、团队结构等各种因素综合考虑。

参考

<< 微服务设计 - Sam.Newman >>