1.2 了解微服务

与Serverless的概念类似，面向微服务的设计策略最近也非常流行。这种架构设计在Serverless的概念出现以前就已经存在很长时间了。就像我们试图通过互联网上的技术定义来理解Serverless架构一样，我们也应通过互联网上的技术定义来理解微服务。微服务的技术定义如下：

“微服务又称为微服务架构，它是一种架构风格，将应用程序构建为一组松耦合的服务，以实现业务功能。”

与Serverless架构一样，规划和设计微服务形式的架构同样有利有弊。我们要熟知微服务架构的优缺点，以便使用时能够扬长避短。在阐述微服务的缺点之前，先来看看它的优点。

微服务能够帮助软件团队保持敏捷和逐步改进。简单来说，由于各个服务之间彼此分离，因此升级和改进一项服务非常容易，并且不会导致其他服务崩溃。例如，在社交网络软件中，如果聊天和订阅功能都是微服务，那么当软件团队尝试升级或者修复聊天服务时，订阅服务完全不会受影响。然而，在大型整体式系统中，很难像微服务那样将功能独立开来。因此，在整体式架构中，即使是一个小组件的修复或者升级都会导致所有服务的停止，而修复所需的时间也往往超出预期。

整体式架构的代码量非常庞大，任何一个小故障都会影响整个系统的运转。微服务则对代码进行了精简和细分，从而极大地提升了开发人员的工作效率。开发人员可以在开销极小甚至为零并且不需要停机的情况下修复和改进服务。容器可以让我们更好地利用微服务，它提供了有效且完整的虚拟操作系统环境，能够隔离进程，并且提供底层硬件资源的专属访问权限。

当然，微服务也有缺点，其中最主要的一点是，它依赖分布式系统。由于各个服务之间是相互独立的，所以架构师需要弄清楚各个服务之间的交互方式，从而构建出功能完整的产品。因此，服务之间的交互方式，以及它们之间数据的传输策略，都是架构师需要认真考虑的问题。分布式系统的主要问题，比如共识、CAP定理、维持共识的稳定性以及连接，都是工程师在构建微服务时需要处理的问题。确保和维护安全性也是分布式系统和微服务中的主要问题。你需要为每个微服务制定单独的安全模式和层级，还需要为服务之间的数据交互制定安全策略。