传统单体架构到微服务化架构的演进之路

1、从传统单体架构到服务化架构

1、Java EE架构

JEE以面向对象的Java编程语言为基础，扩展了Java平台的标准版，是Java平台企业版的简称。它作为企业级软件开发的运行时和 开发平台，极大地促进了企业开发和定制信息化系统的进展。

Java EE将企业级软件架构分为三个层级: Web 层、业务逻辑层和数据存取层，每个层次的职责分别如下。

• Web层:负责与用户交互或者对外提供接口。
• 业务逻辑层:为了实现业务逻辑而设计的流程处理和计算处理模块。
• 数据存取层:将业务逻辑层处理的结果持久化以待后续查询，并维护领域模型中对象的生命周期.

Java EE平台将不同的模块化组件聚合后运行在通用的应用服务器上，例如:WebLogic、WebSphere,JBoss等，这也包含Tomcat，但

Tomcat仅仅是实现了JEEWeb规范的Web容器，Java EE平台是典型的二八原则的一个应用场景，它将80%通用的与业务无关的逻辑和流

程封装在应用服务器的模块化组件里，通过配置的模式提供给应用程序访问，应用程序实现.20%的专用逻辑，并通过配置的形式来访问

应用服务器提供的模块化组件。事实上，应用服务器提供的对象关系映射服务、数据持久服务、事务服务、安全服务、消息服务等通过简

单的配置即可在应用程序中使用。

典型的架构图：

缺点：

• 每个层次的业务逻辑实现放在一个应用项目中，随着复杂业务和外界因素（人员流动），项目的耦合度增加

2、SSH时代

开源软件Struts、Spring和Hibernate，简称SSH

Web MVC框架Struts在用户交互的UI层进一步划分了前端的职责，将用户交互层划分为视图、模型和控制器三大块(简称 MVC模型)，其结构示意图

它的历史我就不说了，直接看架构图如下：

优点：

• 使用方便，灵活，不需要向JEE大量配置xml
• 实现交互UI接口的Web、MVC层、实现业务逻辑的Spring层及实现对象关系映射的Hiberate层,每个层级的实现比JEE应的层次更简单、更轻量级，不需要开启整个应用服务器即可测试和验证，极大提高了开发效率，这得益于Spring框架的控制翻转理念

3、服务化架构

从JEE时代到SSH时代，服务的特点依然就是单体化，服务的粒度抽象为组件，全部耦合在一个项目中，若其中模块需升级上线，未需升级的模块也就会上线。在高并发场景下，单一进程无法满足需求，水平扩展能力有限。

为了解决上述问题，SOA出现了。

SOA：代表面向服务的架构，俗成服务化

SOA是什么？

SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

特点

• SOA定义了良好的对外接口，通过网络协议对外提供服务，服务之间表现为松耦合性、松耦合性具有灵活的特点，可以对服务流程进行灵活组装和编排，而不需要对服务本身做改变
• 组成整个业务流程的每个服务的内部结构和实现在发生改变时，不影响整个流程对外提供服务，只要对外的接口保持不变，则改变服务内部的实现机制对外部来说可以是透明的
• SOA在这一时代的数据通信格式通常为XML，因为XML标记定义在大规模、高并发通信过程中，冗余的标记会给性能带来极大的影响，所以后来被JSON所取代。
• SOA通过定义标准的对外接口，可以让底层通用服务进行下沉，供多个上层的使用方同时使用，增加了服务的可重用性
• SOA 可以让企业最大化地使用内部和外部的公共服务，避免重复造轮子，例如:通过SOA从外部获取时间服务。

主流实现方式

Web Service和EJB

Web Service

使运行在不同机器和操作系统上的服务互相发现和调用成为可能，通过某种协议交换数据

工作原理图

1. 服务提供者Web Service2和WebService3通过UDDI协议将服务注册到WebService目录服务中。
2. 服务消费者WebServicel通过UDDI协议从WebService日录中查询服务，并获得服务的WSDL服务描述文件。
3. 服务消费者WebService1通过WSDL语言远程调用和消费WebService2和Web Service3提供的服务。

Web Service可以发现所有的服务，经过服务编排来服务新的服务

EJB

ESB是企业服务总线的简称，是用于设计和实现网络化服务交互和通信的软件模型，主要用于企业信息化系统的集成服务场景中。Mule是企业服务总线的一个实现。

ESB的架构图：

每个服务通过总线插入系统，总线根据流程的编排将服务的输出转换并发送到另一个服务

职责：

• 监控和控制服务之间的消息路由
• 控制可插拔的服务化的功能和版本
• 解析服务之间交互和通信的内容和格式
• 通过组合、资源和消息处理器来统一编排业务需要的信息处理流程
• 使用冗余来体用服务的备份能力

2、从服务化到微服务

1、微服务的产生

随着互联网用户访问量增加，发起的高并发请求无法解决，前面提到的SOA服务虽然能分解任务，但是仍然存在时代遗留的问题。

Web Service的问题：

• 依赖中心化的服务发现机制
• 使用SOAP通信协议，通常使用XML格式来序列化通信数据，XML格式的数据冗余太大，协议太重
• 服务化管理和治理设施不完善

ESB存在的问题：

• ESB虽然是SOA实现的一种方式，却更多地体现了系统集成的便利性，通过统一的服务总线将服务组合在一起，并提供组合的业务流程服务。
• 组合在ESB上的服务本身可能是一个过重的整体服务，或者是传统的JE服务等
• ESB视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在。
• 对于总线本身的中心化的管理模型，系统变更影响的范围经常会随之扩大

近年来，服务化的架构不断发展和演练，微服务逐渐出现了。

微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制， 通常使用RESTful风格的API形式来通信，因为RESTful风格的API通常是在HTTP或者HTTPS通道上传输JSON格式的数据来实现 的,HTTP协议有跨语言、跨异构系统的优点，当然，也可以通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心 化的统一管理，每个服务的功能可自治，并且可以由不同的语言系统和平台实现。

微服务致力于松耦合和高内聚的效果，与SOA和ESB相比，不在强调服务总线和通信机制的多样性，通过Restful风格和轻量级的消息通信协议来完成。

微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由

于拆分的微服务系统中专业的人做专业的事，人员和项目的职责单一、低耦合、高内聚，所以产生问题的概率就会降到最小。

2、微服务与传统架构的对比

1、微服务架构

从上图可以看出：

• 微服务把每一个职责单一的功能放在一个独立的容器中
• 每个服务运行在一个单独的进程中
• 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效果
• 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等资源。
• 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人员;
• 每个服务都高度自治，内部的变化对外透明.每个服务都可根据性能需求独立地进行水平伸缩

2、传统单体架构

• 传统单体架构将所有模块化组件混合后运行在同一个服务JVM进程中。
• 可对包含多个模块化组件的整体JVM进程进行水平扩展，而无法对某个模块化组件进行水平扩展。
• 某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线
• 久而久之，模块间的依赖将会不清晰，互相耦合、互相依赖成为家常便饭。

3、微服务架构与SOA服务化的对比

SOA服务化架构与微服务架构有些相似，但还是存在不同的地方

1、目的不同

• SOA 服务化涉及的范围更广一些，强调不同的异构服务之间的协作和契约，并强调有效集成、业务流程编排、历史应用集成等，典型代表为WebService和ESB。
• 微服务使用一系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和迭代影响的范围，并达到单一微服务更容易水平扩展的目的

2、部署方式不同

• 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker技术来实现自动化的容器管理，每个微服务运行在单一的进程内，微服务中的部署互相独立、互不影响。
• SOA服务化通常将多个业务服务通过组件化模块方式打包在一个War包里，然后统一部署在一个应用服务器上

3、服务粒度不同

• 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理,拆分到职责单一，甚至小到不能再进行拆分
• SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度

如果觉得内容不错的话，希望大家可以帮忙点赞转发一波，这是对我最大的鼓励，感谢🙏🏻