系列文章目录：
《领域驱动设计》（Eric Evans）：告诉我们用代码呈现真实世界的重要性，并且告诉我们如何更好地建模。
持续交付理论：如何更有效及更高效地发布软件品，并指出保持每次提交均可发布的重要性。
六边形架构理论（Alistair Cockburn）：把我们从分层架构中拯救出来，从而能更好地体现业务逻辑。（http://alistair.cockburn.us/Hexagonal+architecture）
随着领域驱动设计、持续交付、按需要虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也就应运而生。
什么是微服务？
微服务就是一些协同工作的小而自治的服务。
1.小，专注
单一职责原则：把因相同原因而变化的东西聚合在一起，把因不同原因而变化的东西分享开来。（Single Resonsibility Principle，http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle）
微服务将内聚性应用在独立的服务上，根据业务的边界来确定服务的边界，可避免代码库过大衍生的问题。
讨论：多小才算小？
使用代码行来衡量是有问题的。大家都认为自己的系统过于庞大，却不知道什么才算是小。ok，那么就一直拆分，直到你不再感觉它过于庞大，那么它有可能就足够小了。另外，如果你的小团队无法正常维护，那么它就太大了。
小的优点与缺点：独立性带来的好处越多，但管理也越复杂。
2.自治性
一个微服务是一个独立的实体，它可以独立部署，独立修改，服务之间通过暴露API来进行通信，API的实现技术应避免与具体技术相关，以保证技术的选择不受限制。
自治性其实就是要求你的服务与其他的服务之间很好的解藕，判断是否解藕的黄金法则：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？
微服务的好处
1.技术异构性
对于微服务而言，我们可以根据需要采用最适合这个服务所需要的技术。
对于微服务系统而言，总会存在一些地方让我们可以尝试新技术，这种可以快速采用新技术的能力对很多组织而言是非常有价值的。
2.弹性
如果系统中的一个组件不可用，但并没有传染到其他的组件，没有导致级联故障，系统的其他部分还可以正常工作。
3.扩展
庞大的单块服务只能作为一个整体进行扩展，即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以对只需要进行扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。
4.简化部署
在有几百万行代码的单块应用中，即使只修改了一行代码，也需要重新部署整个应用程序才能发布该变更。这种部署影响很大、风险很高，于是部署的频率就会降低，两次部署的差异越大，出错的可能性就更大！
在微服务架构中，各个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署，如果真出了问题，也只会影响一个服务，并且容易快速回滚，这样就意味着客户可以快速使用我们的新功能。
5.与组织结构相匹配
可以避免出现庞大的代码库，从而获得理想的团队大小及生产力。
6.可组合性
分布式系统和面向服务架构的主要好处是易于重用已有功能。不同于以往的单纯的Web、PC端程序，人们有更多的选择使用同一个功能。微服务中会开放很多接口供外部调用，当情况发生改变时，可以使用不同的方式构建应用。
7.可替代
在单块系统中，删除一百行代码会让人心惶惶，而在微服务系统中，可以轻易地重写服务，或删除不再使用的服务。
面向服务的架构（SOA）
SOA是一种设计方法，它通过提供服务向外提供一系列功能，服务之间通过网络调用，而非采用进程内调用的方式进行通信。
SOA可以用来应用庞大的单块应用程序，从而提高软件的复用性，比如多个终端共享一个服务。但大多数人对SOA的理解未达成共识，而微服务就是实现SOA的一种新方法，就像XP或Scrum是敏捷软件开发的一种特定方法一样。
其他分解技术
1.共享库
有些共享库不属于任何一个业务领域，并且可以在整个组织中进行重用。但还是需要小心，如果使用共享库来做服务之间的通信的话，那么它会成为一个藕合点。
2.模块
有些语言提供自己的模块分解技术，它允许对模块进行生命周期管理，这就可以把模块部署到运行的进程中并且可以不在停止整个进程的前提下对某个模块进行修改，但很少有人这么做，因为尽管在单块进程中创建隔离性很好的模块是可能的，但是它们这些模块会迅速和其他代码藕合在一起。
同时，在单进程中采用模块化技术，也会大大限制我们采用新技术和独立服务进行扩展的能力。
参考
《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）