《微服务设计》第 1 章　微服务

第 1 章　微服务

• Eric Evans 的《领域驱动设计》一书帮助我们理解了用代码呈现真实世界的重要性，并且告诉我们如何更好地进行建模。持续交付理论告诉我们如何更有效及更高效地发布软件产品，并指出保持每次提交均可发布的重要性。基于对 Web 的理解，我们寻找到了机器与机器交互的更好方式。Alistair Cockburn 的六边形架构理论（http://alistair.cockburn.us/Hexagonal+architecture）把我们从分层架构中拯救出来，从而能够更好地体现业务逻辑。借助虚拟化平台，我们能够按需创建机器并且调整其大小，借助基础设施的自动化我们也很容易从一台机器扩展到多台。在类似 Amazon 和 Google 这样成功的大型组织中，有很多小团队，他们各自对某个服务的全生命周期负责。最近，Netflix 分享了构建大型反脆弱系统的经验，而这种构建方式在 10 年前是很难想象的
• 随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。它并不是被发明出来的，而是从现实世界中总结出来的一种趋势或模式

1.1　什么是微服务

• 微服务就是一些协同工作的小而自治的服务

1.1.1　很小，专注于做好一件事

• 内聚性是指将相关代码放在一起，在考虑使用微服务的时候，内聚性这一概念很重要
• 把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。”
• 微服务将这个理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样就很容易确定某个功能代码应该放在哪里
• 澳大利亚 RealEstate.com.au 的 Jon Eaves 认为，一个微服务应该可以在两周内完全重写，这个经验法则在他所处的特定上下文中是有效的
• 如果你不再感觉你的代码库过大，可能它就足够小了
• 另外一个帮助你回答服务应该多小的关键因素是，该服务是否能够很好地与团队结构相匹配。如果

1.1.2　自治性

• 一个微服务就是一个独立的实体。它可以独立地部署在 PAAS（Platform As A Service，平台即服务）上，也可以作为一个操作系统进程存在
• 这些服务应该可以彼此间独立进行修改，并且某一个服务的部署不应该引起该服务消费方的变动。对于
• 如果系统没有很好地解耦，那么一旦出现问题，所有的功能都将不可用。有一个黄金法则是：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？

1.2　主要好处

1.2.1　技术异构性

• 如果系统中的一部分需要做性能提升，可以使用性能更好的技术栈重新构建该部分。系统中的不同部分也可使用不同的数据存储技术，
• 下图展示了该异构架构

• 对于微服务系统而言，总会存在一些地方让我可以尝试新技术。你可以选择一个风险最小的服务来采用新技术，即便出现问题也容易处理。这种可以快速采用新技术的能力对很多组织而言是非常有价值的

1.2.2　弹性

• 将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好地处理服务不可用和功能降级问题

1.2.3　扩展

• 使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上

1.2.4　简化部署

• 在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且容易快速回滚，这也意味着客户可以更快地使用我们开发的新功能。Amazon 和 Netflix 等组织采用这种架构主要就是基于上述考虑

1.2.5　与组织结构相匹配

• 微服务架构可以很好地将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力

1.2.6　可组合性

• 分布式系统和面向服务架构声称的主要好处是易于重用已有功能。而在微服务架构中，根据不同的目的，人们可以通过不同的方式使用同一个功能，在考虑客户如何使用该软件时这一点尤其重要

1.2.7　对可替代性的优化

• 使用微服务架构的团队可以在需要时轻易地重写服务，或者删除不再使用的服务

1.3　面向服务的架构

• SOA（Service-Oriented Architecture，面向服务的架构）是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信
• 更好地实施 SOA，而这事实上就是微服务架构。就像认为 XP 或者 Scrum 是敏捷软件开发的一种特定方法一样，你也可以认为微服务架构是 SOA 的一种特定方法

1.4　其他分解技术

1.4.1　共享库

• 基本上所有的语言都支持将整个代码库分解成为多个库，这是一种非常标准的分解技术
• 这种方式存在一些缺点
• 首先，你无法选择异构的技术
• 其次，你会失去独立地对系统某一部分进行扩展的能力。再次，除非你使用的是动态链接库，否则每次当库有更新的时候，都需要重新部署整个进程，以至于无法独立地部署变更。而最糟糕的影响可能是你会缺乏一个比较明显的接缝来建立架构的安全性保护措施，从而无法确保系统的弹性

1.4.2　模块

• 有些语言提供了自己的模块分解技术。它们允许对模块进行生命周期管理，这样就可以把模块部署到运行的进程中，并且可以在不停止整个进程的前提下对某个模块进行修改

1.5　没有银弹

• 微服务不是免费的午餐，更不是银弹，如果你想要得到一条通用准则，那么微服务是一个错误的选择。你需要面对所有分布式系统需要面对的复杂性