体系结构进化框架是适应业务场景而产生的，有业务就有解决方案，即体系结构。
利用面向服务的单体体系结构(如MVC SOA体系结构)和大APP应用技术(按服务划分all in )实现ESB :企业服务总线-支持异构服务、消息和基于事件的交互具有适当服务级别和可管理性的XML :消息交换格式SOAP :用于发布使用wsdl:XML描述服务的接口协议和格式UDDI:wsdlweb服务，该服务通常使用HTTP交换XML格式的消息使用技术，跨平台语言的APP应用接口技术/服务通信技术解决了有缺陷的ESB的沉重复杂组件，主要解决了不同技术架构应用方面的通信(服务注册和发现)，使用xml格式有一种说法认为，还是缺乏中心化统一标准，厂商之间的解决方案很难切换不适合云环境的微服务体系结构，微服务是SOA的变体和子集。 这样，可以理解为微服务的服务分割粒度更小。 soa解决复用问题，微服务解决扩展问题的特点一组小服务独立过程轻量级通信协议可以独立引入多语言不同存储技术优点的分割粒度小，业务单一，焦点集中，服务复用和服务解耦是开发、技术为了更好地实现敏捷开发和DevOps开发运维一体化，容易引入新技术，根据需要扩展的缺点分布式成本：分布式事务、分布式锁定、远程调用的协同成本：一个项目上线需要几十个APP应用这些项目还要求不同团队的维护服务拆分具有较强的设计功力：拆分不好，服务无法实现高聚集性和低耦合性需求服务的爆发，难以管理。 可见，呼叫链路变长、请求时间变长，以及难以跟踪部署和运输的困难，无论是优势还是劣势，都是双方面的。 分割粒度小：好处、服务复用、解耦。 缺点，服务爆炸，呼叫链路变长，难以追踪。 如果不能分割服务，就很难实现高凝聚、低耦合、单一服务的开发、试运营。 但是，一个需求涉及很多服务，有时甚至达到几十个，引进运输困难也不简单。 服务划分后，面临分布式开销和问题、分布式锁定、网络开销、分布式事务等。 广义的微服务不仅需要实现定义内的技术，还需要解决落地问题。 例如，自动部署和运输概念微服务中心的概念是服务可以划分为多个关注点服务注册中心服务列表服务的服务注册服务发现负载均衡硬件负载均衡， 例如F5软件负载均衡服务端负载均衡服务端负载均衡服务容错负载均衡服务容错限制流熔断网关集成接入、路由协议自适应流量管理、限制流安全防护、统一审计权黑白列表、