下载掌阅APP，畅读海量书库
立即打开
在过去，开发人员构建和部署的是 单体应用 （monolithic application）。这是比较专业的说法，在单体应用中 每个功能都被捆绑在一起作为单个大的包 ，如图1-1所示。Web前端、认证、日志生成、数据存储、报告系统等被紧密地耦合在一起，捆绑成一个应用。这意味着，如果想改变某个部分，必须改变 每一部分 。
图1-1
举个简单的例子，如果需要修补或更新图1-1中的应用的报告功能，必须关闭整个应用并修补/更新整个应用。像这样的工作需要详尽的计划，面临巨大的风险且十分复杂，通常还不得不在漫长无聊的周末和大家一起加班完成。
但是，单体应用带来的痛苦还不止于此。如果想对它们的某个功能进行扩缩容，不得不对整个单体应用扩缩容。
基本上，应用的每个功能都被作为一个单体的单元捆绑、部署、升级和扩缩容，这是很笨拙的，显然不是很理想。
另外，微服务应用采用完全相同的一组功能——Web前端、认证、日志生成、数据存储、报告系统等，并将每个功能拆分为自己的小应用。“小”的另一个词是“微”，“应用”的另一个词是“服务”。这就是“微服务”这个术语的由来。
如果仔细观察图1-2你会发现，它就是和图1-1完全相同的一组应用功能。不同的是，每个功能都是独立开发、独立部署的，并且可以独立更新和扩缩容。但它们依然协同工作，创造与单体应用完全相同的 应用体验 。
图1-2
最常见的模式是每个微服务都作为独立的容器来开发和部署。例如，Web前端微服务会是一个容器，认证微服务会是另一个不同的容器，报告系统微服务又会再是不同的容器，以此类推。每个微服务都是独立的，但又是通过网络松散耦合的，以创建相同的应用体验。
通过设计让微服务之间是松散耦合的，这是修改一个微服务而不影响其他微服务的基础。从技术上讲，每个微服务都通过IP网络暴露一个API，让其他微服务能够通过这个API来使用它。
如果不熟悉 API 这个概念，下面这个类比对你可能会有所帮助。
汽车的外形和大小各异，它们配置的可能是直列四缸、水平对卧六缸、八缸的发动机，甚至可能是电动发动机。但是，所有这些复杂的细节都通过使用标准化控制器——方向盘、加速器、刹车踏板和车速表对驾驶员隐藏了。在这个模型中，控制器相当于汽车的API——驾驶员通过它们来使用汽车的功能。这种模型的一个主要优点是，学会驾驶后就能驾驶任何一款汽车。例如，我学开车时用的是一辆前轮驱动的汽车，它配置的是四缸汽油发动机，但我无须学习任何新的驾驶技能就能开全轮驱动的电动汽车，这就是因为标准化的方向盘和脚踏板（API）将发动机和传动系统的复杂细节隐藏起来了。同样，更换汽车的发动机、替换其方向盘和轮胎、升级其排气系统后，驾驶员依然能够驾驶它，而无须学习任何新的驾驶技能。
回到正题——微服务应用。只要没有修改微服务的API，就可以在其他微服务和应用用户不会注意到的情况下对微服务进行修补或更新。
除了让微服务能够独立地更新和扩缩容，微服务 设计模式 还让开发团队更小、更敏捷，能够更快地迭代功能。这是基于Jeff Bezos提出的 两块比萨团队规则 （two pizza team rule）——如果你不能用两块比萨养活一个开发团队，那么这个团队就太大了。一般来说，与大团队相比，2～8人团队的沟通和合作的职场政治因素会更少，也会更敏捷。
微服务设计模式还有其他优点，但希望你能明白——将功能开发成独立的微服务，可以在不影响应用任何部件的情况下对它们进行开发、部署、更新、扩缩容等。
但是，微服务并不完美。如果有很多由不同团队管理的移动部件，微服务可能会变得很复杂，这需要谨慎的管理和良好的沟通。
最后，这两种设计应用的方式——单体与微服务——被称为 设计模式 。微服务设计模式是当前云时代最常见的模式。