企业应用架构随着业务的变化不断演进，每一种架构在某一阶段都非常好地支撑了当时的业务模式，随着业务的发展应用架构也经历了单体架构到SOA再到微服务架构演进。信息化技术刚开始应用于业务时，单体架构就可以实现一个信息系统，随着技术的发展和逐步复杂的业务需求，企业应用架构又经历了客户端/服务器（Client/Server，C/S）、浏览器/服务器（Browser/Server，B/S）、面向服务的架构（Service-Oriented Architecture，SOA）、前后端分离、微服务架构、Serverless 的不同阶段。如今微服务架构正成为企业应用架构的主流。如图1：
今天我们来讲讲微服务架构和面向服务的架构SOA的联系与区别：
从本质上看，单体应用架构的设计都是针对应用本身的设计，而不是针对企业的设计。
SOA是真正意义上的面向企业全局的设计，但SOA因为偏重技术，技术要求偏高而成为一种应用集成的工具。因此，微服务的出现，让大型项目开发变得更加轻量化，降低了开发难度，提高了协同效率和开发效率，也大大降低了耦合度。微服务与SOA看似都是分布式服务化架构，但在服务设计理念以及系统运行架构方面，二者有着本质的区别：
1.服务粒度
企业在信息化的过程中又很多相互隔离的系统，ESB把它们整合起来，为了减少服务之间的交叉引用，方便进行服务的编排，SOA提供了粗粒度的服务能力，即大块业务逻辑的封装。而微服务则更加轻量化，提供单独任务或小块业务逻辑的服务封装。微服务根据业务的功能进行拆分，拆分到每一个服务的功能和职责，拆分到最小单元，服务之间的耦合度越来越小，内聚性越来越好，对于敏捷发布和上线的速度更快，每个服务都能独立部署，方便扩容和缩容，能够有效地提高利用率。
2.去中心化
我们知道企业服务总线ESB可以调用SOA下服务的注册发现和路由，所有需要和外部系统通信的系统都接入ESB，但在实际使用中还是出现很多的问题，首先，ESB本身就很复杂，这增加了系统的复杂度和维护量。其次，由于ESB想要做到所有服务都通过一个通路通信，其本身就是一个中心化的思路，因此ESB很容易成为系统运行的瓶颈。
下图2，微服务架构与SOA的差异很清晰的展示出来，我们可以看到微服务的服务注册中心功能，在应用系统启动时，只进行注册或拉取服务地址，把地址列表缓存在本地客户端，
真正调用时并不会通过服务注册中心，而是直接从本地客户端的服务地址缓存中读取目标地址信息，点对点地发起服务调用，因此运行效率比经过中心节点路由转发要高很多，可以说是一个去中心化的运行架构，消除了单点瓶颈，可扩展性也会更强。
微服务应用开发和发布更加敏捷，当开发者对一个传统的单体应用程序进行变更时，必须做详细的QA 测试，以确保变更不会影响其他特性或功能，开发者在版本迭代或更新应用程序中一个组件，其他的部分不会受到影响。测试微服务应用程序仍然是必需的，但它更容易识别和隔离问题。随着容器技术的发展，微服务的部署也更加方便，从而加快开发速度，并支持 DevOps 和持续应用程序开发。从这一点上看，微服务能够在企业应用的敏捷性上带来一定的优势。
微服务应用采用的技术更加轻量、通用和开放，能够有效地降低对开发者的技术要求。每个微服务一般是自封闭的一个功能模块，有自己的业务逻辑和数据，可以独立部署独立扩展。微服务一般会提供一个固定的模块边界， 允许不同的服务用不同的技术栈， 由不同的团队管理， 服务之间通过接口和契约进行交互。从微服务的划分上看，开发者开发的业务模块更加聚焦，这既在降低对开发人员的要求，也在降低IT对企业的要求。
微服务应用往往比传统的应用能更有效地利用计算资源，这是因为它们通过扩展组件来处理功能瓶颈问题。这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代。最终的结果是有更多的资源可以提供给其他任务，满足企业应用扩展的需求。微服务架构在设计上是针对单体应用的优化，但是如果将微服务架构突破单体应用，而从企业全局进行微服务设计时，则会发现微服务架构能够非常好地满足企业在敏捷性上的需要。
