架构演变过程

架构演变过程

一、架构演变过程

1、单体架构

我们工作中最先接触的单体架构，整个系统就只有一个工程，打包往往是打成了war包，然后部署到单一tomcat上面，这种就是单体架构。

这种架构适合比较小型的系统，比如以前的老系统，比如公司的内部OA系统等等，是一个典型的传统项目的结构。

单体应用架构也就是在早期所学习的JavaEE知识SSH或者SSM架构模式，会采用分层架构模式：数据库访问层、业务逻辑层、控制层，从前端到后台所有的代码都是一个小的开发团队去完成。

优点：

1. 结构简单，部署简单
2. 所需的硬件资源少
3. 节省成本

缺点：

4. 版本迭代慢，往往改动一个代码会影响全局
5. 不能满足一定并发的访问
6. 代码维护困难，所有代码在一个工程里面，存在被其他人修改的风险

2、水平扩展架构

随着业务的拓展，公司的发展，单体架构慢慢的不能满足我们的需求，我们需要对架构进行变动，我们能够想到的最简单的办法就是加机器，对应用横向扩展。

还是会存在版本迭代慢，代码维护困难的问题。而且用户请求往往是读多写少的情况，所以可能真正需要扩容的只是其中一个模块而已，而现在是整个工程都扩容了，这无形中是一种资源的浪费，因为其他模块可能根本不需要扩容就可以满足需求。所以必要对整个工程按照模块进行拆分

3、垂直应用架构

随着业务的拓展，公司的发展访问量逐渐赠的，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。这时候单体应用的架构就不能够满足我们的需求，我们需要将系统里面的按业务维度，模块垂直拆分，这样对于需要水平扩展的节点，是比较友好的。

比如，我的商品系统访问量变大，我就只需要增加商品系统的节点进行水平扩展就可以了。

优点：

1. 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展
2. 一个系统的问题不会影响到其他系统，提高容错率

缺点：

• 系统之间相互独立， 会有重复的开发任务
• 系统之间相互独立， 无法进行相互调用（信息孤岛）

4、分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务。

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现

优点：

• 抽取公共的功能为服务层，提高代码复用性

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护

5、微服务架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理，比如，上面分布式架构中的前台页面系统，需要访问下面多个服务，下面的用户服务也被多个调用者调用。

此时，用于资源调度和治理中心(SOA Service OrientedArchitecture，面向服务的架构)是关键。

基于注册中心的SOA框架，扩展是非常方便的，因为不需要维护分流工具，但我们启动应用的时候就会把服务通过http的方式注册到注册中心。

在SOA框架中一般会有三种角色：

1. 注册中心， 维护了服务列表
2. 服务提供方，启动的时候会把自己注册到注册中心
3. 服务消费方，启动的时候，获取注册中心的服务列表，然后调用的时候从这个服务列表中选择某一个去调用

特点：

1. 扩展灵活
2. 每个应用都规模不大
3. 服务边界清晰

二、微服务架构需要解决的问题

上面我们分析了架构的演变过程，随着系统变得越来越复杂，我们的服务之间的调用变得越来越复杂我们引入了微服务架构，那么在微服务架构下我们要解决什么问题呢

1、服务注册发现

服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。
服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。

2、远程服务调用

服务的提供者和消费者通常位于网络上两个不同的地址，要完成一次远程调用，就必须先建立网络连接。
建立连接后，双方还必须按照某种约定的协议进行网络通信，这个协议就是通信协议。
双方能够正常通信后，服务端接收到请求时，需要以某种方式进行处理，处理成功后，把请求结果返回给客户端。为了减少传输的数据大小，还要对数据进行压缩，也就是对数据进行序列化

3、负载均衡

负载均衡建立在现有网络结构之上，扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

4、限流熔断降级

当一个服务调用另外一个服务，可能因为网络原因、或者连接池满等问题导致频繁出现错误，需要有一种熔断机制，来防止因为请求堆积导致整个应用雪崩。

当发现整个系统的确负载过高的时候，可以选择降级某些功能或某些调用，保证最重要的交易流程的通过，以及最重要的资源全部用于保证最核心的流程

在设置了熔断以及降级策略后，还有一种手段来保护系统，就是限流算法

我们能够通过全链路压测了解到整个系统的吞吐量，但实际上的流量可能会超过我们预期的值，比如存在恶意攻击、或者突然的高峰流量。在这种情况下可以通过限流来保护系统不崩溃，但是对于部分用户来说，会出现被限流导致体验不好的情况。

5、分布式消息

消息队列MQ

6、配置中心

服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。

7、链路监控与预警系统

三、springcloud

官网：https://spring.io/projects/spring-cloud

SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。
是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

• Ribbon，客户端负载均衡，特性有区域亲和、重试机制。
• Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。
• Feign，声明式服务调用，本质上就是Ribbon+Hystrix
• Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。
• Bus，消息总线，配合Config仓库修改的一种Stream实现，
• Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。
• Eureka，服务注册中心，特性有失效剔除、服务保护。
• Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。
• Zuul，API服务网关，功能有路由分发和过滤。
• Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式

springcloud和Dubbo的区别?

• 底层协议：SpringCloud 基于rest的 http协议，Dubbo 基于rpc的 tcp协议，因此dubo的通信性能相对比较好，当然SpringCloud 也可以使用grpc 协议
• 注册中心：SpringCloud 是使用eureka，Dubbo推荐是zookepper，目前主流的都是建议是nacos
• 模型定义：SpringCloud是将一个应用定义一个服务，dubbo将接口定义为一个服务
• 生态：SpringCloud是一个完整的生态，而dubbo是SpringCloud生态中关于服务调用的一种解决方案

四、服务网格架构

1、业务团队的痛点

对于业务开发团队而言，最强的是技术吗？一定不是，业务团队最强的一定是对于业务的理解和熟悉程度。

而业务应用的核心价值，就是为了实现业务场景，而不是写微服务，微服务只是一种实现业务的手段

业务团队除了关心业务之外，他们所面临的最大的挑战在于，如何保证系统的稳定性何可扩展性、如何设计一个安全的open api。如果对服务进行拆分、如何保证跨库的数据一致性。以及对于旧系统的改造。

于公司层面而言，业务团队的压力还来自于时间人力的投入，我们用于被各种deadline赶着走。所以作为一个业务程序员，如果在这个deadline之前还需要花更多的时间投入在spring cloud这些工具的学习上，那无疑是雪上加霜。公司对于业务团队的考核，永远只看结果。

2、微服务存在的技术问题

• 技术门槛高：开发团队在实施微服务的过程中，除了基础的服务发现、配置中心和鉴权管理之外，团队在服务治理层面面临了诸多的挑战，包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等，这对开发团队提出了非常高的技术要求。
• 代码侵入性强：Spring Cloud、Dubbo等主流的微服务框架都对
  业务代码有一定的侵入性，技术升级替换成本高，导致开发团队配合意愿低，微服务落地困难。
• 多语言支持不足：对于互联网公司，尤其是快速发展的互联网创业公司，多语言的技术栈、跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。

3、服务网格ServiceMesh

Sidecar是ServiceMesh中的重要组成部分，Sidecar在软件系统架构中特指边斗车模式，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。 在Service Mesh架构中，给每一个微服务实例部署一个Sidecar Proxy。该Sidecar Proxy负责接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能从服务中抽离到该proxy中。

Sidecar以一个独立的进程启动，可以每台宿主机共用同一个Sidecar进程，也可以每个应用独占一个Sidecar进程。

所有的服务治理功能，都由Sidecar接管，应用的对外访问仅需要访问Sidecar即可。当该Sidecar在微服务中大量部署时，这些Sidecar节点自然就形成了一个服务网格。服务的消费方和提供方主机(或者容器)两边都会部署代理SideCar。

ServiceMesh比较正式的术语也叫数据面板(DataPlane)，与数据面板对应的还有一个独立部署的控制面板(ControlPlane)，用来集中配置和管理数据面板，也可以对接各种服务发现机制(如K8S服务发现)

Service Mesh为业务开发团队降低了门槛，提供了稳定的基础设施，最重要的是，让业务开发团队从微服务实现的具体技术细节中解放出来回归到业务本身。