为了应对诸如惊人的操作开销、重复的努力、可测试性等微服务通常面临的挑战,以及获得诸如代码解耦,易于横向扩展等微服务带来的好处,ZStack将所有服务包含在单个进程中,称为管理节点,构建一个进程内的微服务架构。
动机
构建一个IaaS软件是很难的,这是一个已经从市场上现存的IaaS软件获得的教训。作为一个集成软件,IaaS软件通常需要去管理复杂的各种各样的子系统(如:虚拟机管理器hypervisor,存储,网络,身份验证等)并且需要组织协调多个子系统间的交互。例如,创建虚拟机操作将涉及到虚拟机管理模块,存储模块,网络模块的合作。由于大多数IaaS软件通常对架构考虑不够全面就急于开始解决一个具体问题,它们的实现通常会演变成:
随着一个软件的不断成长,这个铁板一块的架构(monolithic
architecture)将最终变为一团乱麻,以至于没有人可以修改这个系统的代码,除非把整个系统从头构建。这种铁板一块的编程问题是微服务可以介入的完美场合。通过划分整个系统的功能为一个个小的、专一的、独立的服务,并定义服务之间交互的规则,微服务可以帮助转换一个复杂笨重的软件,从紧耦合的、网状拓扑架构,变成一个松耦合的、星状拓扑的架构。
因为服务在微服务中是编译独立的,添加或者删除服务将不会影响整个系统的架构(当然,移除某些服务会导致功能的缺失)。
微服务远比我们已经讨论的内容更多:微服务的确有很多引入注目的优点,尤其是在一个的开发运维 流程(DevOps process)中,当涉及到一个大机构的很多团队时。我们不打算讨论微服务的所有支持和反对意见,我们确定你可以在网上找到大量的相关文章,我们主要介绍一些我们认为对IaaS软件影响深远的特性。
问题
虽然微服务可以解耦合架构,但这是有代价的。阅读Microservices
- Not A Free Lunch!和Failing at
Microservices会对这句话有更深的理解。在这里,我们重点强调一些我们认为对IaaS软件影响重大的事情。
1.难以定义服务的边界和重复做功
创建Microservices架构的挑战之一是决定应该把哪一部分的代码定义为服务,一些是非常明显的,比如说,处理主机部分的逻辑代