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

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

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

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

2. 软件难以部署、升级和维护

3. 零散的配置

4. 额外的监控努力

5. 插件杀手

（详细代码请见文章底部）

所有的服务都在一个进程

意识到上述的所有问题，以及这么一个事实，即一个可以正常工作的IaaS软件必须和所有的编排服务一起运行之后，ZStack把所有服务封装在单一进程中，称之为管理节点。除去一些微服务已经带来的如解耦架构的优点外，进程内的微服务还给了我们很多额外的好处：

1. 简洁的依赖

2. 高可用，负载均衡和监控

3. 中心化的配置

4. 易于部署、升级、维护和横向扩展

5. 允许插件

（详细代码请见文章底部）

进程内的微服务并不是一个新发明：早在90年代，微软在COM（Component Object Model）中把server定义为远程、本地和进程内三种。这些进程内的server是一些DLLs，被应用程序在同一进程空间内加载，属于进程内的微服务。Peter Kriens在四年前就声称已经定义了一种总是在同一进程内通信的服务，OSGi µservices。

服务样例

在微服务中，一个服务通常是一个可重复的业务活动的逻辑表示，是无关联的、松耦合的、自包含的，而且对服务的消费者而言是一个“黑盒子”。简单来说，一个传统的微服务通常只关心特定的业务逻辑，有自己的API和配置方法，并能像一个独立的应用程序一样运行。尽管ZStack的服务共享同一块进程空间，它们拥有这些特点中的绝大多数。ZStack很大程度上是一个使用强类型语言java编写的项目，但是在各个编排服务之间没有编译依赖性，例如：计算服务（包含VM服务、主机服务、区域服务、集群服务）并不依赖于存储服务（包含磁盘服务、基础存储服务、备份存储服务、磁盘快照服务等），虽然这些服务在业务流程中是紧密耦合的。

在源代码中，一个ZStack的服务并不比一个作为一个独立的jar文件构建的maven模块多任何东西。每一个服务可以定义自己的APIs、错误码、全局配置，全局属性和系统标签。例如KVM的主机服务拥有自己的APIs和各种各样的允许用户自己定义配置的方式。

（服务样例相关详细代码请见文章底部）

以上，就是本期的云补习啦，对架构感兴趣的小伙伴欢迎参考以下步骤自行到官网探索更多ZStack架构相关噢~

产品下载请戳：

https://www.zstack.io/help/product_manuals/maintenance_manual/2.html#c2_1

产品手册：

https://www.zstack.io/help/product_manuals/