分布式：软件架构演变、服务化到微服务、分布式和微服务

【问题】分布式是什么？分布式是指将一个计算机系统或应用拆分成多个独立的子系统，这些子系统分布在不同的计算机或服务器上，并通过网络连接互相通信，协调工作，以完成一致的任务目标的一种计算机技术。

【问题】为什么要分布式呢？首先，分布式技术可以将大型系统分解成小型组件，从而降低单个组件的复杂度，便于开发和维护。其次，分布式技术可以实现负载均衡，提高整个系统的性能和可伸缩性。此外，分布式系统还具备容错性，即当一个节点出现故障时，其他节点仍然可以继续运行，从而提高了系统的可靠性。

【问题】分布式又会有哪些问题？

• 数据一致性问题：由于数据分散在不同的节点上，如何保证数据的一致性成为一个难题。
• 网络延迟和通信故障问题：分布式环境下，节点之间的通信必须通过网络完成，网络通信故障或延迟会严重影响系统的性能和可靠性。
• 节点故障问题：分布式系统中，每个节点都可能出现故障，如何保证在这种情况下系统仍能正常运行也是需要考虑的问题。

【问题】分布式系统是如何实现事物的？分布式系统实现事务一般采用两阶段提交（2PC）协议。该协议可以确保分布式环境下所有节点都能提交或回滚一个事务，从而保证系统的数据一致性。在 2PC 协议中，一个事务分为两个阶段，即投票阶段和提交阶段。投票阶段中，协调者询问参与者是否可以提交事务，并等待参与者的响应；如果所有参与者都可以提交，则进入提交阶段，否则回滚事务。在提交阶段中，协调者通知所有参与者提交事务，如果所有参与者都成功的提交了事务，则整个事务提交完成，否则回滚事务，以保证系统的一致性。

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

1.1，JEE架构（JSP+Servlet）

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

JEE将企业级软件架构分为三个层次：Web层、业务逻辑层和数据存取层（MVC），每个层次的职责分别如下：

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

JEE平台将不同的模块化组件聚合后运行在通用的应用服务器上，例如：WebLogic、WebSphere、JBoss等，这也包含Tomcat，但Tomcat仅仅是实现了JEE Web规范的Web容器。JEE平台是典型的二八原则的一个应用场景，它将80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里，通过配置的模式提供给应用程序访问，应用程序实现20%的专用逻辑，并通过配置的形式来访问应用服务器提供的模块化组件。事实上，应用服务器提供的对象关系映射关系、数据持久服务、事务服务、安全服务、消息服务等通过简单的配置即可在应用中使用。（JSP+Servelt仅仅需要配置web.xml就可以就可简单使用）

​

JEE时代的架构已经对企业级应用的整体架构进行逻辑分层，包括视图层、业务逻辑层和数据存取层。不同的层级有自己的职责，并从功能类别上划分层级，每个层级的职责单一。

由于在架构上把整体的单体系统分成具有不同职责的层级，对应的项目管理也倾向于把大的团队分成不同的职能团队，主要包括：用户交互UI团队、后台业务逻辑处理团队、数据存取ORM团队与DBA团队等，每个团队只对自己的职责负责，并对使用方提供组件服务质量保证。

因此，在分层架构下需要对项目管理过程中的团队进行职责划分，并建立团队交流机制。根据康威定律，设计系统的组织时，最终产生的设计等价于组织的沟通结构。换句话说，团队的交流机制应该与架构分层交互机制相应。

​

JEE时代下对传统的单体架构进行了分层，职能团队的划分也反应了架构分层，架构已经在一定程度上进行了逻辑上的拆分，让专业的人做专业的事儿初见端倪，但是，每个层次的多个业务逻辑的实现会被放在同一个应用项目中，并且运行在同一个JVM中。尽管大多数公司会使用规范来约束不同业务逻辑的隔离性来解耦，但是久而久之，随着复杂业务逻辑的迭代增加及开发人员的不断流动，新手工程师为了节省时间和赶进度，非法使用了其他组件的服务，业务组件之间、UI组件之间、数据存取之间的耦合性必然增加，最后导致组件与组件之间难以划清界限，完全耦合在一起，将来的新功能迭代、增加和维护将难上加难。

另外，由于JEE主要应用于企业级应用开发，面向的用户较少，所以尽管JEE支持Web容器和EJB容器的分离部署，这个时代的大多数项目仍然部署在同一个应用服务器上并跑在一个JVM上。

1.2，SSH架构（SSM，SpringBoot）

在JEE开始流行但没有完全奠定其地位时，开源软件Struts2、Spring和Hibernate开始崭露头角，很快成为行业内企业开发的开源框架标配，JEE规范中的各种技术如EJB由于学习成本高，XML配置文件多，难以做单元测试等问题迅速失去了发展的机会。WebMVC框架Struts在用户交互的UI层进一步划分了前端的职责，将用户交互划分为视图、模型和控制器三大模块（MVC）。MVC详解

​

SSH时代，Struts MVC模型几乎服务于大多数企业服务的Web项目。后来，开源软件Spring的发布，更加改变了JEE一开始制定的战略目标。Spring框架作为逻辑层实现的核心容器，使用起来简单、方便又灵活，几乎大部分开发者完全倒向了Spring开源派。Spring框架有两个核心思想：IOC和AOP。

• IOC详解：Spring：IoC（控制反转、依赖注入、循环依赖）_燕双嘤-CSDN博客_控制反转如何解决循环依赖
• AOP详解：Spring：面向切面编程（AOP）_燕双嘤-CSDN博客

Spring IOC：指的是控制反转，将传统EJB基于容器的开发改造成普通的Java组件的开发，并且在运行时由Spring容器统一管理和串联，服务于不同的流程，在开发过程中对Spring容器没有强依赖，便于开发、测试、验证和迁移。使用EJB实现一个服务化组件Bean时，需要依赖多个容器接口，并需要根据容器的规则进行复杂的XML配置，测试需要依赖于应用服务器的环境，有诸多不便；使用Spring框架则不然，开发业务逻辑时每个业务逻辑的服务组件都是独立的，而不依赖于Spring框架，借助于Spring容器对单元测试的支持，通过对下层依赖服务进行Mock，每个业务组件都可以在一定范围内进行单元化测试，而不需要启动重型的容器来测试。

Spring AOP：AOP代表面向切面编程，通常适用于使用面向对象方法无法抽象的业务逻辑，例如：日志、安全、事务、应用程序性能管理（APM）等，使用它们的场景并不能用面向对象的方法来表达和实现，而需要使用面向切面来表达，因为它们可能穿插在程序的任何一个角落里。在Java的世界里，AOP的实现方式有如下三种：

• 对Java字节码进行重新编译，将切面插入字节码的某些点和面上，可以使用cglib库实现。
• 定制类加载器，在类加载时对字节码进行补充，在字节码中插入切面，增加了除业务逻辑外的功能，JVM自身提供的Java Agent机制就是在加载类的字节码时，通过增加切面来实现AOP的。
• JVM本身提供了动态代理组件，可以通过它实现任意对象的代理模式，在代理的过程中可以插入切面的逻辑。可以使用Java提供的APIProxy.newProxyInstance()和InvocationHandler来实现。

另外，AspectJ是实现AOP的专业框架和平台，通过AspectJ可以实现任意方式的字节码切面，Spring框架完全支持AspectJ。

到现在为止，SSH开源标配框架中有了UI交互层的Struts框架和业务逻辑实现层的Spring框架，由于面向对象领域的模型与关系型数据库存在天然的屏障，所以对象模型和关系模型之间需要一个纽带框架，也就是我们常说的ORM框架（链接），它能够转化关系，也可以将关系转化成对象，于是，Hibernate框架出现了。Hibernate通过配置对象与关系表之间的映射关系，来指导框架对对象进行持久化和查询，并且可以让应用层开发者像执行SQL一样执行对象查找。这大大减少了应用层开发人员写SQL的时间。然而，随着时间的发展，高度抽象的ORM框架被证明性能有瓶颈，因此，后来大家更倾向于使用更加灵活的MyBatis来实现ORM层。

这一时代SSH框架与JEE时代架构类似，可分为三个层次：实现交互UI接口的Web MVC层、实现业务逻辑的Spring层及实现对象关系映射的Hibernate层，每个层级的实现比JEE对应的层次更简单、更轻量级，不需要开启整个应用服务器即可测试和验证，极大提高了开发效率，这得益于Spring框架的控制反转理念。

由于SSH时代的企业级软件服务的对象仍然是企业，用户量并不大，因此，大多数企业里的SSH架构最终会被打包到同一个JEE规范的War包里，并且部署在Apache Tomcat Web容器里，因此，整个结构还是趋向于传统的单体架构，业务逻辑仍然耦合在一个项目中，即使通过规范来约束模块化组件的耦合度，效果也往往适得其反。

SSH时代的职能团队的划分仍然停留在层次上，与JEE架构的智能团队划分类似，分为前端团队、后端业务逻辑研发团队和DBA团队。

1.3，服务化架构

从JEE时代到SSH时代，服务的特点仍然是单体化，服务的粒度抽象为模块化组件，所有组件耦合在一个开发项目中，并且配置和运行在一个JVM进程中。如果某个模块化组件需要升级上线，则会导致其他没有变更模块化组件同样上线，在严重情况下，对某个模块化组件编程，由于种种原因，会导致其他模块化组件出现问题。

另外，在互联网异军突起的环境下，传统JEE和SSH无法满足对海量用户发起的高并发请求进行处理请求，无法突破耦合在一起的模块化组件的性能瓶颈，单一进程已经无法满足需求，并且水平扩展的能力也很有限的。

为了解决上面的问题，SOA出现了。SOA代表面向服务的架构，俗称服务化。SOA将应用程序的模块化组件通过定义明确的接口和契约联系起来，接口是采用中立的方式进行定义的，独立于某种语言、硬件和操作系统，通常通过网络通信来完成，但是并不局限与某种网络协议，可以是底层的TCP/IP，可以是应用层的HTTP，也可以是消息队列协议，甚至可以是约定的某种数据库存储形式。这使得各种各样的系统中的模块化组件可以以一种统一和通用的方式进行交互。

对比JEE和SSH时代的模块化组件后发现，SOA将模块化组件从单一进程中进一步拆分，形成独立的对外提供服务的网络化组件，每个网络化组件通过某种网络协议对外提供服务，特点如下：

• SOA定义了良好的对外接口，通过网络协议对外提供服务，服务之间表现为松耦合性，松耦合性具有灵活的特点，可以对服务流程进行灵活组装和编排，而不需要对服务本身做改变。
• 组合整个业务流程的每个服务的内部结构和实现在发生改变时，不影响整个流程对外提供服务，只要对外接口保持不变，则改变服务内部的实现机制对外部来说可以是透明的。
• SAO通过定义标准定义标准的对外接口，可以让底层通用服务进行下沉，供多个上层的使用方同时使用，增加了服务的可重用性。
• SOA通过定义标准的对外接口，可以让底层通用服务进行下沉，供多个上层的使用方同时使用，增加了服务的可重用性。
• SOA可以让企业最大化地使用内部和外部的公共服务，避免重复造轮子，例如：通过SOA从外部获取时间服务。

 SOA实现方式：Web Service和ESB。

Web Service

Web Service技术是SOA服务化的一种实现方式，它使得运行在不同的机器及操作系统上的服务的互相发现和调用成为可能，并且可以通过某种协议交换数据。

从图中可以看出，每个服务之间是对等的，并且互相是解耦的，通过WSDL定义的服务发现接口进行访问，并通过SOAP协议进行通信。SOAP协议通常是一种在HTTP或者HTTPS通道上传输XML数据来实现的协议，但是每个服务都要依赖中心化Web Service目录来发现现存的服务。

Web Service的工作原理如下：

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

通过这个过程，要改造一个新的业务流程，可以从Web Service目录中发现现有的服务，并最大限度地重用现有的服务，经过服务流程的编排来服务新的业务。

ESB

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

在SOA服务化发展之前，企业对信息化系统进行了初步建设，这些企业信息化系统由异构技术栈实现：不同的开发语言、操作系统和系统软件为了快速响应新的市场，完全使用新技术重建所有的信息化系统是不现实的，在现有的服务系统上增加新的功能或者叠加新的服务化系统的方法更加可行，这需要对这些现有的信息化系统和新增的信息化系统进行组合。SOA凭借其松耦合的特性，正好应用于这一场景，使得企业可以按照服务化的方式来添加新服务或升级现有服务来解决新业务对流程编排的需要，甚至可以通过不同的取到来获得外部服务，并与企业的现有应用进行组合，来提供新的业务场景所需的信息化流程。

ESB也适用于事件处理、数据转换和映射、消息和事件异步队列顺序处理、安全和异常处理、协议转换和保证通信服务的质量等场景。

ESB服务没有中心化服务节点，每个服务提供者都是通过总线的模式插入系统，总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务。

ESB的核心在于企业服务总线的功能和职责：

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

企业服务总线是ESB的核心要素，所有服务都可以在总线上插拔，并通过总线的流程编排和协议转接能力来组合实现业务处理能力。

2，从服务化到微服务

2.1，微服务架构（SpringCloud）

随着互联网的不断发展，互联网产品需要服务的用户量逐渐增加，海量用户发起的大规模、高并发请求是企业不得不面对的，虽然SOA服务化系统能够分解任务，让每个服务更简单、职责单一、更易于扩展，但无论是Web Service还是ESB，都有时代遗留的问题。

Web Service的问题：

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

ESB的问题：

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

由于上述问题，近年来服务化架构设计得到了进一步的演化和发展，微服务架构已经出现在不同公司的讨论和设计中，并且在实践的过程中证明，微服务设计模式起到了正向作用，以至于在不同的公司里，每个人都在以微服务来设计系统架构，但并不是所有同行都意识到他们使用的就是微服务架构模式，而是在默默享受微服务给软件设计、实现和运行带来的好处。

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

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

微服务架构也并不是一个全新的概念，最早可追溯到UNIX操作系统的实现。在UNIX操作系统的脚本中，每个技术人员都会使用管道，管道连接前后两个命令，前面命令的输出通过管道传送给后一个命令作为输入，每个命令“各自为政”，完成各自的功能需求。从对比来看，管道中的每一个代表微服务，它们高度自治并完成自己的职责，然后将结果输出。管道类似于微服务的网络通信协议，负责微服务之间的交互。

微服务架构不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业的事，人员和项目的职责单一、低耦合、高内聚，所以产生的问题概率会降到最小。

2.2，微服务架构与传统架构的对比

微服务架构：

从图中我们可以看出：

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

传统单体架构：

从图中我们可以看出：

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

通过对比，微服务架构更灵活并且可水平伸缩，可以让专业的人来做专业的事。

2.3，微服务架构和SOA服务化的对比

微服务架构与SOA服务化架构有一些相似的特点，事实上微服务与SOA服务化架构并不冲突，它们一脉相承，微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华并落地的一种实现方式。SOA服务化的理念在微服务架构中仍然有效，微服务在SOA服务化上进行了演进和叠加，形成了适合现代化应用场景的一个方法论。其中的区别：

目的不同：

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

部署方式不同：

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

服务粒度不同：

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

3，分布式和微服务

3.1，分布式和微服务

首先，分布式系统是计算元素的集合，每个计算元素都能够相互独立地工作。我们通常将计算元素称为节点，它可以是硬件设备或软件进程。第二个因素是用户(无论是人还是应用程序)认为他们在处理一个系统。这意味着自治节点以某种方式需要协同和作。如何建立这种协作是开发分布式系统的核心。

微服务：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

目的不同：

• 分布式系统应使资源易于访问，隐藏资源分布在网络上的事实，开放的，可伸缩的。重在资源共享与加快计算机速度，强调的是服务化以及服务的分散化。
• 微服务架构倡导将软件应用设计成多个独立开发、可配置、可运行和可维护的子服务。重在于松耦合和高内聚的效果，使每个模块独立，强调服务的专业化和精细分工。

主流观点：

• 分布式属于微服务：分布式只是一种手段，把不同的机器分散在不同的地方，然后这些机器间相互协助完成业务。微服务是一种特殊的分布式，换句话说，微服务架构是分布式服务架构的子集。微服务架构通过更细粒度的服务切分，使得整个系统的迭代速度并行程度更高，但是运维的复杂度和性能会随着服务的粒度更细而增加。
• 微服务属于分布式：微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。但是微服务不一定是分布式，因为微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。

个人观点：微服务是一种实际应用技术，而分布式是一个很广的理论概念。微服务在思想上基于分布式计算，在物理部署上通常也是分布式的，当然也不排除少数一定要部到同一台机器上。如果硬要归结关系，我认为微服务是分布式系统设计和架构的理念之一，也是分布式系统实际落地应用的一种体现。