系统架构演变历史及集群、分布式、微服务、SOA的概念区别

1：系统架构演变历史

单体架构 ==> 垂直架构 ==> 前后端分离 ==> EAI架构 ==> SOA架构 ==> 微服务 ==> 微服务2.0

• 1、单体架构：在软件设计时经常使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，所以典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。（大单体）
• 2、垂直架构：将原来的一个大项目，按照业务场景拆分为互不相干的单体架构的项目（纵向拆分）
• 3、前后端分离：在前后端分离的架构中，前端关注页面的样式与动态数据的解析及渲染，而后端专注于具体业务逻辑，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。（横向拆分）
• 4、EAI架构：将异构平台的业务系统进行集成的一种技术，主要解决各个系统各自为政，相互无法连通，形成信息孤岛的问题。EAI使用中间件作为粘合剂，来连接各个业务相关的异构系统、数据源，从而满足应用系统之间信息共享的需要。（连通相互独立的系统，解决信息孤岛）
• 5、SOA架构：将各个系统的不同功能单元抽象为服务，服务间彼此通过标准的接口协议连接起来，并以此完成特定功能的实现。当出现新的业务需求时，不需要从零开始实现，只需将已有的服务进行编排装配来实现新业务。（服务复用与编排）
  *6、微服务：微服务是SOA思想的一种提炼，它强调业务系统彻底的组件化和服务化，通过有效的拆分系统，实现敏捷开发和部署。原有的单个业务系统被拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。（SOA是对异构系统的服务化，微服务专注服务的拆分）
  （1）微服务1.0时代：基于 SpringCloud 或者 dubbo 框架进行开发，仅使用服务注册与发现与服务网关等策略
  （2）微服务1.5时代：使用了熔断、限流、降级等服务治理策略，并配备完整服务工具和平台
• 7、微服务2.0：以 ServiceMesh 为代表，将服务治理作为通用组件并下沉到平台层实现，使得应用层仅仅关注业务逻辑。将业务所有的流量都转发到 ServiceMesh 的代理服务中，由服务网格帮助应用程序在海量服务、复杂的架构和网络中建立稳定的通信机制。此外，ServiceMesh 还承担了微服务框架所有的功能，包括服务注册发现、负载均衡、熔断限流、认证鉴权、缓存加速等，不同的是，Service Mesh强调的是通过独立的进程代理的方式。（以代理的方式建立稳定的通信）

1：单一应用架构-ORM

起初，系统之间仅仅是把表现层、业务层、持久层分离开，可以实现解耦合，但是这是在同一台服务器上运行整个系统，客户端可以有多个，他们都将访问同一个终端处理器。但是这种单机部署很可能带来这些问题：系统难以维护、发生单点故障、扩展性差等问题。

适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。
缺点： 1、性能扩展比较难
2、协同开发问题
3、不利于升级维护

2：垂直应用架构-MVC

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。[进程内调用]

通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。
缺点： 公用模块无法重复利用，开发性的浪费

3：面向服务框架-SOA

SOA，即面向服务架构，它最基本的业务功能单元是服务，将各个系统的不同功能单元抽象为服务，实现不同模块的解耦，服务间彼此通过标准的接口协议连接起来，从而实现各异构系统间的服务调用、消息交换和资源共享，并以此完成特定功能的实现。而不同服务间通信的桥梁，就是由服务总线担当的，一般是 ESB

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)[ Service Oriented Architecture]是关键。

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

SOA体系结构中的角色包括：

 1、服务请求者

      是一个应用程序、一个软件模块、另一个服务。他发起对注册中心的服务的查询，通过传输绑定服务、并且执行服务功能，服务请求者根据接口契约来执行服务。

 2、服务提供者

      是一个可通过网络寻址的实体，他接受和执行来自请求者的请求，他将自己的服务和接口契约发布到服务注册中心。

  3、服务注册中心

       是服务发现的支持者，他包含一个可用服务的存储库，并运行感兴趣的服务请求者查询服务提供者接口。

4：微服务架构

微服务是 SOA 思想的一种提炼，它强调的重点之一就是业务系统彻底的组件化和服务化，通过有效的拆分应用，实现敏捷开发和部署。原有的单个业务系统被拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间松耦合，并且使用轻量级协议进行通信（备注：SOA是对异构系统的服务化，微服务专注服务的拆分）

1：微服务的特点：

• 每个微服务有自己私有的数据库持久化业务数据，并且只能访问自己的数据库，而不能访问其它服务的数据库
• 如果一个事务中需要操作多个数据库，这种情况也不能直接访问其它微服务的数据库，只能通过对于微服务提供的接口进行操作。
• 数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的技术。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理

2：微服务主要解决的问题与场景：

• 服务复用，降低成本。企业内部不同的应用间都会有一些通用的东西，比如通知、授权等，将这些服务复用起来，避免重复造轮子

• 支持快速迭代。单体应用无法满足业务增长的需求，DevOps 理念就是要支持快速迭代，如果应用架构不改，是无法在 DevOps 实践中实现快速迭代的。拆分成微服务之后，针对特定服务发布，影响小，风险小，成本低。频繁发布版本，快速交付需求。

• 高可用、高弹性和高性能。解决单体应用的业务可靠性、稳定性问题，随着时间的推移越来越多的问题。

3：微服务的缺点：

• 系统维护：服务数量比单体服务更多，部署、管理的工作量很大

• 稳定性：稳定性下降，一个服务出现故障 ，可能导致整个系统挂掉，同时整个应用被分散成多个服务，定位故障点非常困难。

• 系统测试：原本单个程序的测试变为服务间调用的测试，测试变得更加复杂。微服务化之后，单一模块无法独立完成业务功能，而集成测试会在非常靠后的时候才能做，就要求需要大量引入 API 自动化测试等测试方法。

• 开发方面：

  • 项目初期，业务简单与用户量小，单体项目的开发成本最低，开发效率最高，而选择微服务架构，需要准备很多资源，开发成本较高，开发的效率也就很低。
  • 如果当前规模恰到好处，把服务迸一步拆分不仅不会降低复杂性，反而会让系统变得更复杂。所以不是所有的应用程序都适合被拆分成微服务。同时如果拆分不好，会大量引入分布式事务，处理起来会比较麻烦；
  • 如果应用程序要求各个组件和服务之间紧密集成，比如需要快速处理实时数据的应用程序。在服务之间添加新链路会导致处理速度变慢。
  • CAP原则：由于服务无状态和引入了分布式，较难解决事务一致性问题

• （解决上面四个问题的核心在于：持续部署、全链路监控、自动化测试、服务拆分策略）
  

2:集群和分布式，微服务和soa概念和区别理解

1、分布式架构介绍：

1.1、什么是分布式架构：

​分布式，顾名思义就是将服务拆分成不同的部署单元并部署在不同的机器上，一个服务可能负责几个功能，且各分开部署的部分彼此通过各种通讯协议交互信息。通过分布式架构，可以解决前面介绍单体架构提到的 项目不断变庞大时产生的各种不利于系统长期稳定发展的问题，包括代码质量、开发效率、系统可靠性和扩展性等，但是分布式在解决单体架构中的问题的同时，也引进了其他问题，比如：

（1）系统间耦合度变高，调用关系错综复杂，难以维护。
（2）在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。

1.2、分布式架构的类型：

• 面向服务架构(Service Oriented Architecture，SOA)：以业务服务的角度和服务总线的方式 （一般是WebService与ESB）考虑系统架构和企业IT治理；
• 分布式服务架构（Distributed Service Architecture，DSA)：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理；
• 微服务架构（MicroServices Architecture，MSA)：微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。

2：集群和分布式的区别

集群是个物理形态，分布式是个工作方式。

• 分布式：一个业务分拆多个子业务，部署在不同的服务器上
• 集群：同一个业务，部署在多个服务器上

集群模式：

集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。区别集群的方式是根据部署多台服务器业务是否相同。

注：集群模式需要做好session共享，确保在不同服务器切换的过程中不会因为没有获取到session而中止退出服务。

一般配置Nginx*的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量。

分布式模式：

将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。

下面：service A、B、C、D 分别是业务组件，通过API Geteway进行业务访问。

3：微服务和soa区别

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
（1）SOA 和微服务是一脉相承的，微服务是 SOA 思想的一种提炼，是经过良好架构设计的 SOA，使用一系列微小服务来实现单个应用的方式，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署。

（2）微服务与敏捷开发的思想高度结合在一起，微服务框架将能够带来更大的敏捷性，并为构建应用提供更轻量级、更高效率的开发，而 SOA 更适合大型企业中的业务过程编排、应用集成。

（3）从服务粒度上，SOA 的服务粒度要粗一些，而微服务倡导服务的细粒度，专注于服务的拆分，重用组合，服务粒度足够小到不能再进行拆分，而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度。微服务是以 SOA 的思想进入到单个业务系统内部实现彻底的组件化和服务化，原有的单个业务系统拆分为多个可以独立开发、设计、运行和运维的小应用，这些小应用可独立地进行开发、管理和加速，应用之间通过服务完成交互和集成，每个小应用除了完成本身的业务功能外，还需要消费外部其它应用暴露的服务，同时也将自身的能力朝外部发布为服务。
（4）去中心化：SOA 注重的是系统集成，而微服务关注的完全分离，微服务架构采用去中心化思想，服务之间采用统一的协议和格式，例如 REST、RPC 等轻量协议通信，相比 ESB 更轻量。为了统一管理微服务系统，可以部署一个统一的网关，作为系统的唯一入口。网关封装了系统内部架构，为每个客户端提供一个定制的API。除此之外，网关还可以用于身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。两者的架构如下图所示：

SOA 更适合需要与许多其他应用程序集成的大型复杂企业的应用程序环境，小型应用程序不适合 SOA 架构，因为它们不需要消息中间件组件。而微服务架构，更适合于较小和良好的分割，基于Web的系统。如果你开发的是互联网应用，并且没有历史遗留问题，请优先考虑采用微服务架构。

3：微服务框架

市面常用微服务框架有：Spring Cloud 、Dubbo 、kubernetes

• 从学习成本上考虑，Dubbo 版本趋于稳定，稳定完善、可以即学即用，难度简单，Spring cloud 基于Spring Boot，需要先掌握Spring Boot ，例外Spring cloud 大多为英文文档，要求学习者有一定的英文阅读能力
• 从开发风格考虑，Dubbo倾向于xml的配置方式，Spring cloud 基于Spring Boot ，采用基于注解和JavaBean配置方式的敏捷开发
• 从开发速度上考虑，Spring cloud 具有更高的开发和部署速度
• 从通信方式上考虑，Spring cloud 基于HTTP Restful 风格，服务于服务之间完全无关、无耦合。Dubbo 基于远程调用，对接口、平台和语言有强依赖性，如果需要实现跨平台，需要有额外的中间件。
• 所以Dubbo专注于服务治理；Spring Cloud关注于微服务架构生态。

4：服务通信RPC和HTTP

在单体应用中，各模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是微服务应用是运行在多台机器上的，一般来说，每个服务实例都是一个进程。微服务必须使用进程间通信机制来交互。而常见的通信协议主要有 RPC 和 REST 协议。

REST 和 RPC 都常用于微服务架构中，微服务的好处之一，就是不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦。 但是，如果没有统一的通信框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等 “业务之外” 的重复技术劳动，造成整体的低效。所以，统一通信框架把上述 “业务之外” 的技术劳动统一处理，是服务化首要解决的问题。
（1）REST：

REST 是一种架构风格，指的是一组架构约束条件和原则，满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源，它是通过 HTTP 协议实现，使用 HTTP 协议处理数据通信，更标准，更通用，因为无论哪种语言都支持 http 协议。常见的 http API 都可以称为Rest 接口。REST 提供了一系列架构系统参数，作为整体使用，强调组件交互的扩展性、接口的通用性、组件的独立部署、以及减少交互延迟的中间件，它强化安全，也能封装遗留系统。

（2）RPC：

RPC 是一种进程间通信方式。允许像调用本地服务一样调用远程服务，通信协议大多采用二进制方式。RPC 框架的目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发者在使用时只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率。

• 灵活性方面：在微服务架构中，各个服务间千差万别，REST 的调用和测试都很方便，但使用 RPC 则会有很多约束。
• 性能方面：RPC 协议性能更高，如果算上序列化，吞吐量大概能达到 REST 的二倍，响应时间也更为出色。
• 开放与通用性：REST 通过 http 实现，相对更加规范与通用，无论哪种语言都支持 http 协议。而如果 RPC 需要对外开放的话，需要进一步处理。所以如果是对外开放的 API，一般使用 REST 协议，内部服务的调用则采用性能更高的RPC方式。
• 代码的耦合度：RPC 与代码的耦合度高，而 REST 对代码松散耦合。

强烈推荐这位大佬的文章：常见的服务器架构入门：从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh