1架构演进
架构十五年：改变的是形态，不变的是目的
业务驱动架构形态变化
过去十几年，随着互联网发展以及业务的多样化，系统的架构也在不断发生变化，总体上来说大体经历了从单体应用架构-垂直应用架构-分布式架构-SOA架构-微服务架构的演变，当前各大企业都在朝着数字化转型和云原生方向前进。
业务驱动与基础设施的进化推动架构发展
“架构要解决业务需求的问题，业务需求的变化驱动着架构的进化”。谭待在采访时说道。从互联网的角度出发，结合业务的主要变化，国内软件架构这15年的发展大致
可以分为三个阶段。
第一阶段，互联网正式爆发。这一阶段的特点是网页与用户数据的迅速增多，无论是当时流行的搜索引擎、社交网络，还是工业、电商等行业，互联网的爆发带来的数据量是传统的单机和简单的架构模式无法支持的，传统的架构也无法解决相应的业务问题。因此，软件架构就慢慢从原来的单机系统演变成分布式系统以解决新业务形态带来的问题，诸如在架构层面考虑容错、负载均衡等问题。同时需要注意的是，也正是这个时候开启了后来所谓的大数据时代。
第二阶段， 移动互联网的兴起。移动互联网兴起之后，互联网业务的形式又随之发生了比较大的变化。PC互联网时代比较典型的一个例子就是搜索引擎，搜索引擎对时效性要求并不是特别高，对用户来说只要能找到所需要的内容即可，不追求实时在线，这个时候架构更多解决的是吞吐量大的问题。移动时代则不同，推荐、个性化服务已经成为更主流的方式，业务的场景也变成了对实时性要求非常高的情况。
这一阶段架构方面主要的变化就是计算从以前的批量计算变成了流式计算，数据处理从离线变成实时，比较典型的例子就是Hadoop到Spark，再到后面Flink的变化。这其中的变化就涵盖了系统架构对用户数据的处理、文档数据的处理、推荐、广告算法等等，这个时期业务对架构的范式要求更高。另外，这一时期硬件等基础设施的大幅提升与大规模的应用，也对架构的演进起到了非常大的推动作用。
第三阶段，云原生时代。也就是当下，企业上云对许多公司来说已经变成一种默认行为。这个时候业务架构就需要基于云原生进行改造，如何基于云组件做适配，如何合理使用云的弹性、计算存储分离等功能也变的至关重要。如果继续使用老的业务架构跑在云上，那无异于“拉着马车跑在高速公路上”。
云原生出现之后还衍生了一个有趣的现象，在云原生到来之前，企业软件架构与互联网软件架构是分离的，现在这两者已经开始慢慢交融在一起。传统的厂商需要进行数字化转型，其面临的业务需要互联网化，要解决高并发、大吞吐等问题，势必要采用互联网架构。互联网公司经过多年的发展壮大，内部运营管理上也会面临传统企业的问题，比如如何解决开发效率，如何解决新老系统并存，如何进行数据打通等等。总的来说，业务场景的需求变化驱动着架构的演进。PC互联网时代、移动互联网时代、云原生时代（数字化转型时代）的业务需求是不同的，也就对不同时期的架构提出了更多的要求。另外软硬件等基础设施的创新和开源价值的体现等也都对架构的演进起到了非常大的助推作用。
1.1单体架构
单体架构是今天绝大多数软件开发者都学习、实践过的一种软件架构，许多介绍微服务的图书和技术资料中也把这种架构风格的应用，称作“巨石系统”（Monolithic Appplication）。
概述
（1） 单体架构在整个软件架构演进的历史进程里，出现的最早、应用范围最广、使用人数最多、统治时间最长的一种架构风格。
（2） 但单体这个名称，是在微服务流行之后，“事后追认” 所形成的的概念。此前，没有多少人将“单体”看作一种架构。很少有教如何开发单体架构的开发资料。这一方面体现单体架构的简单性，另外一方面体现出在相当长时间里，大家已经习惯了软件架构就是单体的这种样子。
（3） 单体不一定就不好，一般有问题的是“大型单体系统”，而不是小型单体系统。
对于小型系统，单台机器足以支撑起良好的运行系统，不仅易于开发、测试、部署，而且系统中各个功能、模块、方法的调用都是进程内调用，不会发生进程间通信（Inter-Process Communication, IPC）,因此，运行效率也是最高的。
（4） 单体系统的不足，必须在软件的性能需求超过了单机、软件人员规模明显超过了“2张披萨”（2 Pizza Team）范畴前提下才有讨论的价值。
（5） 单体系统一般也是分层的。分层架构（Layered Architecture）是现在所有系统中普遍认可，采用的软件设计方法，无论是单体还是微服务，亦或是其他架构风格，都会对代码进行纵向层次划分。 如果常见的：表示层-》业务层-》持久层-》数据库层，像目前很多传统企业都在用的SpringMVC框架、SSH框架、SSM框架等都可以发布到单体服务器进行应用。
（6） 另外，单体架构也支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。单体系统并不意味只有一个整体的程序封装形式，如果需要，它完全可以由多个JAR，WAR，DDL，Assembly 或者其他模块格式来构成。即使从横向扩展（Scale Horizontally）角度衡量，在负载均衡器之后同时部署若干个单体副本系统，以达到分摊流量压力的效果。
单体架构的优缺点
1、优点
单体系统所有代码运行在同一个进程内，所有模块、方法的调用都无须考虑网络分区、对象复制的性能损失。进程内的调用简单、高效。发布、部署简单，方便运维。
2、缺点
（1）任何一部分代码出现缺陷，过度消耗进程空间内的资源，所造成的营销也是全局性的，难以隔离的。项目大而笨重，改动一处都要进行重新打包、发布。
（2）譬如：内存泄露、线程爆炸、阻塞、死循环等问题，不仅仅影响某个一个功能、模块的正常运作，还会影响整个程序。
（3）如果出问题的是某些更高层次的公共资源，譬如端口号或者数据库连接池泄露，还将会影响整台机器甚至集群中其他单体副本的正常工作。
（4）由于隔离能力的缺失，单体难以阻断错误传播、不便于动态更新程序。还面临难以技术异构的困难，每个模块的代码通常都需要使用一样的程序语言，乃至一样的框架去开发。
微服务取代单体的最重要原因：单体系统架构风格要求每一个部件、每一处代码都尽量可靠，尽量不出或少出缺陷。然而,当系统规模越来越大时，交付一个可靠的单体系统就变得越来越具有挑战性。软件架构的演进，构建可靠系统的观念“追求尽量不出错”到正视“出错是必然”的转变，才是微服务架构得以挑战并逐步取代单体架构的主要原因。
允许程序出错，获得自治与隔离能力，以及可以实现技术异构等目标，是继性能与算力之后，让程序再次选择分布式的理由。SOA 就是曾经的探索过的方法之一。新旧世纪之交（20世纪-21世纪）用来对一个大的单体系统拆分为若干个更小的，不运行在同一进程的独立服务，这些服务的拆分方法后来带来了面向服务架构的一段兴盛期。
1.2 分布式架构
分布式系统是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。严格意义上来说，它属于是部署层面的架构思想，但是它也属于我们后面所说的微服务。
这种做法的好处是，可以提高系统的运算能力。与分布式系统相对应的就是 单体应用系统，单体应用系统的思想是all in one 思想， 就是全部在一起，一个系统的全部服务都集中在一个网络节点上。
集群
从分布式部署架构上延伸出来的集群概念：所谓集群就是，相同的事情多个人做，比如在上图分布式系统中， 商品服务 被部署到一台机器上，但是如果在购物节时，请求太多，一台机器根本扛不住，这时我们也增加10台机器，这10台机器都部署 商品服务, 这样由这10台机器就组成了商品服务集群，集群的初衷就是提高系统的吞吐量，另一个就是提高可用性，比如一台服务器挂了，不至于服务不可用。
缺点
虽然分布式架构能解决一系列问题，但是它经常和后面说的SOA、微服务架构结合使用，分布式架构是从软件部署层面来描述的。它固然也存在很多复杂的问题，如，事物一致性等。
1.3 SOA架构
SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”，它是一种设计理念，其中包含多个服务， 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。它是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA不是一种新鲜事物，它是在企业内部IT系统重复构建以及效率低下的背景下提出的。在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。
实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。
服务消费者（Service Consumer）可以通过发送消息来调用服务，这些消息由一个服务总线（Service Bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引（Business Rules Engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（Service Management Infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（Regulatory Requirement），例如 Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
SOA所要解决的核心问题
系统间的集成 : 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如 ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。
系统的服务化 : 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。
业务的服务化 : 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】。
SOA架构的时代特性
SOA软件架构时代，包含了许多概念、思想，在今天的微服务中有能找到对应的身影，譬如：
服务之间的松散耦合、注册、发现、治理、隔离、编排等。
SOA 对这些问题，包括“软件开发”，都指导的更具体，更系统，如下：
更具体：
SOA本身属于抽象概念，不是某一种具体的技术
1、比**单体架构、烟囱式架构（Information Silo Architecture）、微内核架构 （Microkernel Architecture）、事件驱动架构（Event-Driven Architecture）**操作性更强。
2、不能简单的认为是一种架构风格，更是一套软件设计的基础平台
3、有清晰的指导原则：eg：服务的封装性、自治、松耦合、可重用、可组合、无状态等等
4、采用SOAP作为远程调用协议，依靠SOAP协议族（WSDL、UDDI和WS-*协议）来完成服务的发布、发现和治理。
5、利用ESB企业服务总线（Enterprise Service Bus，ESB）的消息管道来实现各个子系统之间的交互，令各服务在ESB的调度下无须相互依赖就能相互通信，实现了服务的松耦合，也为后续进一步实现业务流程编排（Business Process Management，BPM)提供了基础。
6、使用服务数据对象（Service Data Object， SDO）来访问和表示数据
7、使用服务组件架构（Service Component Architecture， SCA）来定义服务封装的形式和服务运行的容器。
更系统：
SOA终极目标希望总结出一套自上而下的软件研发方法论，做到企业只需要跟着SOA的思路，就能一揽子解决掉开发过程中的全部问题。譬如：该如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发/测试/部署新的功能等。
SOA还关注研发过程涉及的需求、管理、流程和组织。
SOA 21世纪最初的10年里曾盛行一时，有IBM等一众行业巨头厂商为其呐喊冲锋，吸引了不少软件开发厂商，尤其企业级开发商，但最终还是偃旗息鼓，沉寂下去。
SOAP协议被逐渐边缘化的原因：
简单说就太复杂了。
过于严格的规范定义带来过度的复杂性，而构建在SOAP基础上的ESB、BPM、SCA、SDO等诸多上层建筑加剧了这种复杂性。
过于精密的流程和理论需要懂得复杂概念的专业人员才能驾驭。
可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种广泛普适性的软件架构风格来推广。
SOA架构思想过时么？
答案 NO！！！，因为Apache Dubbo 框架便是这种思想。
1.4 微服务架构
概述
微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
和SOA架构简单比较：
1、 微服务是一种SOA思想的延续，任然关注服务，但是强调是"微",微体现的是服务开发成分要低，职责要尽量单一，同时部署也要灵活方便。目前微服务是非常流行的一种软件架构，在Java生态中 SpringCloud就提供了微服务的全站解决方案。
2、微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。
3、微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。
和分布式架构的简单比较：
微服务架构和分布式架构的区别是部署方式不一样。分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。微服务的应用可以部署在是同一个服务器，不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式，它将一个复杂的大型应用程序划分成多个微服务，这些小型服务都在各自独立的进程中运行。
1.5 微服务架构与SOA架构的区别
本小节内容参考自：https://www.toutiao.com/article/6919733527265182219/?channel=&source=search_tab&wid=1660266617488
SOA本身的定义： SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。
在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，其一是找到各个遗留系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。
因此SOA更多的是一种架构思想，进一步总结是：基于遗留系统已有可复用的能力，分层组装的方式来构建上层业务应用。
只要我们在架构设计的时候符合这个思想即是SOA。
在谈SOA的时候一般会将SOA和ESB服务总线结合起来谈。即认为SOA即是一个类似ESB总线的进行业务系统间接口集成和统一管控的集成平台。
而ESB总线仅仅是实现SOA架构思想的一个工具，在前面谈SOA架构思想谈到一个是识别可重用的接口服务并统一管理，这个即是需要ESB总线来完成；另外一个就是对可复用的服务进行服务组装或编排，而这个能力往往通过BPEL或BPM来完成。如下图所示：
即SOA架构思想的实现涉及到ESB总线和BPM产品的使用。同时接口的识别和定义是依托在遗留IT系统已有的能力暴露，而不是新产生的能力。
因此ESB总线一般也用于多个遗留系统之间的接口服务集成和统一管理。
从SOA到微服务
首先看下微服务的一个定义：微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
SOA和微服务的区别，即：
微服务架构强调的第一个重点就是原来的单体业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。
如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
对于微服务实际本身又强调了几个重点，简单总结如下：
- 拆分后的微服务从数据库，逻辑层到前端都完全独立松耦合。
- 微服务间通过轻量HTTP API接口交互。
- 微服务间以去中心化方式调用，不需要中心化总线平台。
上面三点实际上是我们谈微服务的时候经常会谈到的三点。而对于微服务这个概念本身实际包括了微服务模块和微服务API接口两个部分内容，即：
传统单体=拆分多个微服务（微服务模块+暴露Http API接口）
当谈微服务的时候一定是和传统的单体应用对比来说的，如果没有传统单体应用，也没有当前的微服务的概念。单体应用太大，太重了所以需要拆分，同时拆分微服务还需要通过轻量高性能的接口完成交互和协同。
当把这个理解清楚后，你会看到SOA和微服务实际出发点和目标完全是不同的，虽然两者都会针对传统的单体应用或遗留系统来谈，但是要达到的效果不同。
- SOA和ESB：遗留单体应用暴露可复用接口，并通过接口完成多系统集成。
- 微服务：遗留单体应用进行拆分，拆分为多个微服务，再去中心化集成。
如果从一个单体应用改造为微服务，那么微服务将通过类似服务注册中心等去中心化的方式完成集成。但是如果一个单体应用需要类似APP应用等前端访问，往往仍然需要一个统一的代理网关来对外暴露接口，这个即常说的API网关。
API网关可以理解为一个轻量的ESB总线能力实现。
API网关不仅仅实现了服务代理和API接口的位置透明，同时也实现了类似服务安全，限流熔断，日志，监控等关键的服务治理管控能力。
SOA是否过时？
再回到这篇文章的主题，即在微服务和云原生时代，微服务是否过时的问题。在前面已经解释了SOA和微服务的一些概念和区别。实际上你会看到SOA和微服务反而不是同一个层面的两个概念。原来业务系统构建中的组件化才是和微服务对等的一个概念。
在云计算不断发展演进过程中，整个IT架构也在不断地发展演进，新的技术也在层出不穷，有些老的技术过时也是常见现象。但是当前实际是很多人连SOA是什么都还没有搞清楚，就在说SOA已经过时，这种人就是典型的追热点，炒概念的人。
包括最近已经听到很多人在说中台过时了，阿里在拆中台了，同样这些人连中台究竟是什么？中台思想本质在哪里都没有搞清楚就在批评中台。包括有些提供中台服务的厂商，把中台吹得天花乱坠，无所不能，结果一到了客户内部最终建设实施发现无法落地，发现原来的业务问题同样无法解决，反而引入了更加难以管理的IT复杂度。
任何一个概念重点是理解思想，基于思想来考虑如何应用和落地实践。
对于SOA，经常看到的过时说法主要包括如下几点：
- 微服务是去中心化的，SOA还是中心化集成老架构。
- 微服务是Http API轻量接口，SOA下还是SOAP WS接口。
- SOA和ESB很重并紧耦合，而微服务下轻量集成并松耦合。
当然还有其他的一些说法，重点都是在强调SOA中心化，SOA架构是很重的架构不再能够灵活地适应业务变化和扩展。
因此，基于以上问题，再逐一展开分析和描述。
ESB总线和API网关
注意API网关本身也是一个中心化的API接口集成架构。
在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？
在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。
如何给API网关一个定义？
简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。
内部的微服务对外部访问来说位置透明，外部应用只需和网关交互
统一拦截接口服务，实现安全，日志，限流熔断等需求
从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：
大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
进行数据的复制映射，路由等能力
对于两者，我原来做过一个简单的对比，大家可以参考。
因此一个应用内部的微服务模块之间可以去中心化集成，但是这个应用需要和传统的遗留IT系统，需要和外部APP等进行接口集成的时候，往往就需要借助API网关的能力来完成。
API网关本身也是中心化的架构。
即使对于一个应用内部，只要存在类似外部APP前端需要访问后端服务接口，那么就引入了API网关，整个架构就很难说是一个完全意义上的去中心化架构。
因此，简单地说微服务完全去中心化，这个说法是不成立的。
新老架构并存时仍然需要ESB总线
同时在微服务架构实施过程中，一个微服务应用本身还需要和传统的遗留IT系统之间集成，只要还存在这种传统的遗留IT系统，那么这种集成场景就存在，仍然需要通过类似ESB总线或轻量的SOA服务总线来完成接口集成和管控工作。
我们以一个集成场景来进行说明，即企业遗留系统集成采用ESB服务总线，而对于新建设的一个微服务应用采用API网关，那么就存在两者协同和集成的过程，整体集成架构如下：
可以看到，在这种集成架构下，微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到API网关，同时API网关暴露的服务进一步集成和注册到ESB服务总线，形成两级服务集成的方式。
在这种两级服务集成模式下好处包括
微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到网关和ESB
内部微服务间的Rest API交互仍然可以走注册中心，而且对外透明
可以进一步使用ESB总线协议转换和适配能力，完成SOAP和Rest接口转换和适配
虽然两级集成模式下增加了一定的性能损耗，也拉长了整个服务调用链路。但是在新旧架构并存的过程中，这种两级集成仍然是我们推荐采用的方式。既满足了微服务应用内部的微服务治理要求，又实现了和外围系统间的集成。
全微服务化应用构建场景
接着再谈下如果一个企业所有的IT系统都全新构建，同时都采用微服务架构方式进行构建。那么这个时候是否可以做到完全意义上的去中心化架构，所有的微服化间都通过注册中心去中心化的方式调用和集成。
对于企业信息化来说，即使全微服务化，那么传统应用的虚拟边界还在，这个短期并不能马上改变。即类似供应链应用，合同应用，HR应用都采用微服务架构开发，但是这个应用的虚拟边界还在，这个应用边界存在的作用包括了：
- 通过应用需要划分不同的开发组织或开发团队。
- 应用之间是粗粒度的API接口集成，而非整个微服务集成。
当谈到这里的时候，你会看到仍然存在多个应用之间的集成问题需要解决。这个集成即可以采用轻量的API网关来完成。
举例来说，合同应用拆分为10个微服务，10个微服务间可以去中心化集成。同时其中有一个APP前端微服务，这个在合同应用建设中引入了微服务网关来解决统一代理和出口问题。同时合同应用自己搭建了服务注册中心，服务限流熔断能力等。
在合同应用内部，管控的粒度是到微服务粒度即可。
但是当合同应用需要和供应链应用交互的时候，这个时候不可能将某个合同的微服务模块完全暴露给供应链应用，而是只能够暴露一个个粗粒度的API接口服务。
如果合同，供应链，HR三个应用只搭建一个类似Eureka服务注册中心，那么三个应用之间的访问和边界将出现完全混淆和不可控。这个不仅仅是安全类问题，也同样存在接口乱用导致的紧耦合集成等问题。
从一个企业整个IT应用架构来看，打破虚拟应用的边界，做到完全去中心化是一个艰难并漫长的过程。这个涉及到组织级IT管控治理能力成熟度，组织，开发，运维各个过程间的标准规范制定等。
所以不要简单地说全新架构和全微服务化后，整个应用域就能够做到完全的去中心化。实际上每个应用之间仍然难以去中心化，最佳的方式仍然是通过API网关或SOA总线来完成集成和交互。
SOA思想从来没有过时
对于SOA来说，重点不是ESB总线引擎，而是SOA参考架构思想。SOA架构思想里面虽然也有遗留系统的适配和集成，但是更加重要的是从传统的竖向应用构建思路转变为横向分层构建思路，同时抽取和识别可重用服务，通过服务组装来满足上层业务应用。
在谈中台的时候我就指出过，中台思想实际上SOA思想和微服务两者的融合。为何这样讲，我们来讲中台思想和中台实现两个层面来说。
- 共性可复用业务能力下沉，并提供给前台应用使用=》SOA思想
- 共性能力构建时候尽量大拆小，可扩展，松耦合=》微服务思想
当前互联网企业谈的中台基本就是SOA架构思想和微服务两者的一个融合，既体现了共性业务能力下沉，又体现了共性能力要大拆小的微服务方式构建。如下图：
当我们理解了这个核心概念后，我们才能够认识到如下几点关键认识。
中台是一个业务层面概念，微服务是一个技术层面概念。中台核心仍然是共性业务能力下沉和复用，只是互联网企业在实现中台架构的时候，将中台技术实现和微服务做了融合。
因此企业内业务中台实现，只要满足共性业务能力统一提供给上层使用，即使底层提供能力的仍然是传统遗留业务系统，那么也可以将构建了一个业务服务能力中台。
同时也可以看到微服务仅仅是中台中应用到的一个技术实现，你可以在很多非中台场景下采用微服务，小到原来一个业务系统拆分后全新构建这种场景。
在中台构建中，中台和前台之间实际还需要一个中台提供的API接口服务的组装和编排层，也可以理解为进一步的领域服务整合能力，而这个服务组合层，实际上和前面谈到SOA里面的服务组装编排思想是完全一致的。
当重新思考中台这个概念的时候，你会发现中台本质还是SOA架构思想。在我们最终规划和建设SOA集成平台，ESB总线的时候就希望构建一个企业内部的服务能力共享平台，为新的应用构建提供可复用接口服务能力。
这个和当前中台思路是完全一致的。也就是说企业传统SOA架构规划实施中都难以落地实施的事情，绝对不是简单地将概念包装为中台就能够落地的，包括当前中台还涉及到传统IT架构的微服务化，更加难以推进。这个也是大量中台项目建设失败或夭折的原因。
结语
最后简单总结下前面谈到的内容，即：
SOA架构思想从来就不存在过时的说法，同时当企业存在遗留IT系统，包括遗留IT系统逐步迁移和微服务的情况，往往同时存在ESB服务总线和API网关并存的情况。或者也可以采用ESB总线来提供API网关应该具备的能力。
随着这个技术发展，企业IT治理管控能力加强，云原生整体技术推进，治理能力的提升，才可能逐步做到完全的去中心化架构。
我们实施了很多大型的SOA集成平台和ESB总线项目，同时也实施了微服务架构规划咨询和迁移类项目，更加认为企业IT架构微服务化是一个漫长过程，一定要围绕业务目标驱动，逐步迁移和演进，最终达到一个目标架构。
1.6 SOA架构的分析案例
SOA落地方式
SOA的落地方式与水平，跟企业IT特点、服务能力和发展阶段直接相关。目前常见的落地方式主要有分布式服务化和集中式管理两种。
1.分布式服务化
互联网类型的企业，业务与技术发展快，数据基数与增量都大，并发访问量高，系统间依赖关系复杂、调用频繁，分布式服务化与服务治理迫在眉睫。通过统一的服务化技术手段，进一步实现服务的注册与寻址、服务调用关系查找、服务调用与消息处理监控、服务质量与服务降级等等。现有的一些分布式服务化技术有dubbo(基于java)、finagle(基于scala)和ICE（跨平台）等。
2.ESB集中式管理
传统企业的IT内部遗留系统包袱较重，资源整合很大一部分是需要打通新旧技术体系的任督二脉，所以更偏重于以ESB作为基础支撑技术，以整合集成为核心，将各个新旧系统的业务能力逐渐的在ESB容器上聚合和集成起来。比较流行的商业ESB有IBM的WMB和oracle的osb，开源esb有mule、servicemix、jbossesb、wso2esb和openesb。
1.7 总结
基于架构的演进这里做个整体概述，我们知道还有一个比较出名的框架，即 Apache Dubbo ，它是一个分布式的Rpc 框架，毕竟RPC就是为了解决分布式架构中的服务之间的通信、应用与服务之间的通讯问题。
Apache Dubbo 背景及需求
以下内容摘自官网：https://dubbo.apache.org/zh/docsv2.7/user/preface/background/
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
**结语：**架构的演进或多多少都离不开SOA架构的思想，了解各种架构的关系、了解服务编排与治理，才能更好的设计出自己企业合适的架构。
参考资料：
【1】https://www.pdai.tech/md/arch/arch-x-service.html
【2】https://blog.csdn.net/asdcls/article/details/122162652
【3】https://www.leixue.com/ask/what-is-the-difference-between-microservice-architecture-and-distributed-architecture
【4】https://zhuanlan.zhihu.com/p/336649999
【5】https://mp.weixin.qq.com/s?__biz=MzkyNTI5NTQ1NQ==&mid=2247499596&idx=1&sn=42744e9b34aacc96d53737b82582ae87&source=41#wechat_redirect
【6】https://www.toutiao.com/article/6919733527265182219/?channel=&source=search_tab&wid=1660266617488