ZStack--进程内的微服务架构

为了应对诸如惊人的操作开销、重复的努力、可测试性等微服务通常面临的挑战，以及获得诸如代码解耦，易于横向扩展等微服务带来的好处，ZStack将所有服务包含在单个进程中，称为管理节点，构建一个进程内的微服务架构。

动机

构建一个IaaS软件是很难的，这是一个已经从市场上现存的IaaS软件获得的教训。作为一个集成软件，IaaS软件通常需要去管理复杂的各种各样的子系统（如：虚拟机管理器hypervisor，存储，网络，身份验证等）并且需要组织协调多个子系统间的交互。例如，创建虚拟机操作将涉及到虚拟机管理模块，存储模块，网络模块的合作。由于大多数IaaS软件通常对架构考虑不够全面就急于开始解决一个具体问题，它们的实现通常会演变成：

随着一个软件的不断成长，这个铁板一块的架构（monolithic
architecture）将最终变为一团乱麻，以至于没有人可以修改这个系统的代码，除非把整个系统从头构建。这种铁板一块的编程问题是微服务可以介入的完美场合。通过划分整个系统的功能为一个个小的、专一的、独立的服务，并定义服务之间交互的规则，微服务可以帮助转换一个复杂笨重的软件，从紧耦合的、网状拓扑架构，变成一个松耦合的、星状拓扑的架构。

因为服务在微服务中是编译独立的，添加或者删除服务将不会影响整个系统的架构（当然，移除某些服务会导致功能的缺失）。

微服务远比我们已经讨论的内容更多：微服务的确有很多引入注目的优点，尤其是在一个的开发运维 流程（DevOps process）中，当涉及到一个大机构的很多团队时。我们不打算讨论微服务的所有支持和反对意见，我们确定你可以在网上找到大量的相关文章，我们主要介绍一些我们认为对IaaS软件影响深远的特性。

问题

虽然微服务可以解耦合架构，但这是有代价的。阅读Microservices

• Not A Free Lunch!和Failing at
  Microservices会对这句话有更深的理解。在这里，我们重点强调一些我们认为对IaaS软件影响重大的事情。

1.难以定义服务的边界和重复做功

创建Microservices架构的挑战之一是决定应该把哪一部分的代码定义为服务，一些是非常明显的，比如说，处理主机部分的逻辑代码可以被定义为一个服务。然而，管理数据库交互的代码非常难以决定应不应该被定义为服务。数据库服务可以使得整个架构更加清