1、前言

2、通信机制

2.1 简介

     在单体应用中，模块之间的调用通信通过引用加载方法或者函数来实现，但是单体应用最终都会因为团队壮大，项目模块的扩展和部署等出现难以维护的问题。随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务可以弥补单体应用不足，是一种更加快速高效软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的独立模块，单独部署，然后共同组成一个应用程序。把范围限定到单个独立业务模块功能。分布式部署在各台服务器上。一般来说，每个微服务都是一个进程。而各服务之间的交互必须通过进程间通信（IPC）来实现

 2.2 交互模式

交互模式有以下几种方式：

• 请求/响应：客户端向服务器端发起请求，同步等待响应，等待过程可能造成线程阻塞。
• 通知（也就是常说的单向请求）：客户端请求发送到服务端，服务端不返回请求响应。
• 请求/异步响应：客户端发送请求到服务端，服务端异步响应请求。客户端不会阻塞，而且被设计成默认响应不会立刻到达。

• 发布/ 订阅模式：客户端发布通知消息，被零个或者多个订阅者服务消费。

• 发布/异步响应模式：客户端发布请求消息，然后异步或者回调服务发回响应。

服务之间的通信可以使用同步的请求/响应和请求/异步响应模式，在surging框架采用的基于RPC的netty 请求/异步响应和基于rabbitmq 的消息通信模式。首先来看异步消息通信模式

2.1.1 异步消息通信模式

Surging采用基于Rabbitmq发布订阅的异步交换消息的IPC进程通信，客户端通过pub发布请求，然后服务端进行Consume，之间的通信是异步，客户端不会因为等待而阻塞。

   消息由头部（元数据）和消息体构成，生产者发送消息到channel,消费者则通过channel接受数据，channel 则分为点对点和发布订阅，点对点Channel 会把消息准确发送到消费者，之间采用的是一对一的交互模式。而发布/订阅则把消息PUB到所有从channel 订阅消息的消费者中，之间采用的一对多的交互模式

2.1.2 基于请求/异步响应通信模式

Surging采用基于netty的 （IPC）进程通信，是基于请求/异步响应的IPC机制，客户端向服务端发送请求，服务端处理请求，异步响应，客户端不会因为等待服务返回而阻塞其它请求。

在请求/异步响应模式中，服务器端异步响应是在多处理器系统上可以并行处理或者单处理上交错执行，这使得当某个线程阻塞请求的同时其它线程得以继续执行。但访问共享资源时，需要保证其线程安全，可以通过锁，先进先出集合或者其它机制来处理线程安全的问题。

3、部署和调用

1.单体应用架构

当网站流量很小时，只需要将所有功能部署在一起，以减少部署节点和成本

单体架构业务流程往往在同一个进程内部完成处理，不需要进行分布式协作，它的工作原理如下：

 

图 1-1 单体架构本地方法调用

 

2.垂直应用架构

当访问量逐渐增大，单体架构压力越来越大，将架构拆成互不相干的若干应用以提升效率，此时采用MVC、webAPI进行调用

 

3.分布式微服务架构

当垂直应用越来越多，应用之间交互不可避免，可以将各个独立的业务模块，部署成独立的微服务，逐渐形成稳定的服务中心。

而Surging 微服务采用分布式集群部署方式，服务的消费者和提供者通常运行在不同的进程中，进程之间通信采用RPC方式调用，它的工作原理如下：

                                                                         图1-2 Surging分布式RPC调用

        Surging微服务采用基于netty进行通信，数据之间的传递通过序列化和反序列JSON,相比于本地方法调用，会产生如下问题：

       1.数据序列化问题：微服务进程的通信都需要经过序列化和反序列化，因数据结构不一致、数据类型的不支持、编码错误都会造成数据转化的失败，从而导致调用失败

       2.网络问题：常见的包括网络超时、网络闪断、网络阻塞等， 都会导致微服务远程调用失败。

       每个微服务都独立打包部署，让服务之间进行进程隔离，对于大型的互联网项目，会有成百上千的微服务，通常不会百分百独立部署，对于同一业务的微服务会打包部署在一起，对于时延非常敏感，会合设在同一进程之内，采用本地方法调用。

不同的微服务合设在同一进程中，会产生以下问题：

1. 处理较慢的微服务会阻塞其它微服务
2. 某个微服务故障，可能导致整个进程不可用

3、总体架构

　　Surging框架代码逻辑一共划分了8层，各个层的设计要点：

• 业务模块服务接口层（IModuleServices）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方，设计业务模块接口。
• 业务模块服务层（ModuleServices）：该层是通过Domain和Repository实现实际业务逻辑
• 基础通信平台（CPlatform）：提供基础数据通信对应的接口和基础实现，如：基础日志，远程调用服务，Event bus,负载均衡算法，数据序列化等
• DotNetty服务层（DotNetty）：实现基于DotNetty服务的信息的发送和接收
• RabbitMQ服务层（EventBusRabbitMQ）：封装基于Rabbitmq的发布订阅的事件总线
• 代理服务层（ProxyGenerator）：封装代理服务的生成及创建调用。
•  服务注册层（Zookeeper）：封装服务地址的注册与发现，以Zookeeper为服务注册中心，实现ServiceRouteManagerBase抽象，通过心跳检测的方式更新路由
• 系统服务层（system）：对于系统底层接口的封装

4、分布式的可靠性

      Surging 微服务的运行质量，除了自身的可靠性因素之外，还受到其它因素的影响，包括网络，数据库访问，其它关联的微服务的运行质量，可靠性设计，需要考虑上述综合因素，总结如下：

     

4.1 异步I/O 操作

　　4.1.1 网络I/O

　　1.同步阻塞I/o 通信：

　　即典型的请求/响应模式。  该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈1:1的正比关系，线程数量快速膨胀后，系统的性能将急剧下降，随着访问量的继续增大，系统最终崩溃。

1. 异步非阻塞I/O 通信：

　　Surging 是基于Netty进行异步非阻塞I/O 通信，即典型的请求/异步响应模式。此模式的优点如下：

1. 更好的吞吐量，低延迟，更省资源
2. 不再因过快、过慢或超负载访问导致系统崩溃

　　4.1.2 磁盘I/O

　　微服务对磁盘I/O的操作主要分为同步文件操作和异步文件操作，

　　在Surging项目中，需要从注册中心获取路由信息缓存到本地，通过创建代理，负载均衡算法选择Router，路由信息的缓存到采用的是心跳检测的方式进行更新。

　　4.1.3 数据库操作

　　一般来说文件 I/O、网络访问乃至于进程间同步通信，以及本节所讨论的 数据库访问等都较为耗时，ado.net，Entity Framework以及其它ORM框架都提供了异步执行方法。

4.2 故障隔离

　　由于大部分微服务采用同步接口调用，而且多个领域相关的微服务会部署在同一个进程中，很容易发生“雪崩效应”，即某个微服务提供者故障，导致调用该微服务的消费者、或者与故障微服务合设在同一个进程中的其它微服务发生级联故障，最终导致系统崩溃。为了避免“雪崩效应”的发生，需要支持多种维度的依赖和故障隔离，

　　4.1.1 通信链路隔离

　　由于网络通信本身通常不是系统的瓶颈，因此大部分服务框架会采用多线程+单个通信链路的方式进行通信，原理如下所示：

      

　　4.1.2 调度资源隔离

　　4.1.2.1微服务之间隔离

　　当多个微服务合设运行在同一个进程内部时，可以利用线程实现不同微服务之间的隔离。

4.3 进程级隔离

对于核心的微服务，例如商品用户注册、计费、订单等，可以采用独立部署的方式，实现高可用性。

4.3.1 容器隔离

　　微服务将整个项目解耦成各个独立的业务模块，部署成独立的微服务，利用Docker 容器部署微服务可以升级和扩容，并且有以下优点：

　　高效：使用Docker部署微服务，微服务的启动    和销毁速度非常快，在高压力时，可以实现秒级弹性伸缩。

　　高性能：Docker 容器的性能接近逻辑，比VM高20%

　　隔离性：可以实现高密度的部署微服务，而且是基于细粒度的资源隔离机制，实现微服务隔离，保证微服务的可靠性

　　可移植性：通过将运行环境和应用程序打包到一起，来解决部署的环境依赖问题，真正做到跨平台的分发和使用。可谓是一次编写，到处运行。

4.3.2 VM隔离

　　除了Docker容器隔离，也可以使用VM对微服务进行故障隔离，相比于Docker容器，使用VM进行微服务隔离存在如下优势：

　　1.微服务的资源隔离性更好，CPU、内存、网络等可以实现完全的资源隔离。

　　2.对于已经完成硬件虚拟化的遗留系统，可以直接使用已有的VM，而不需要在VM中重新部署Docker容器。

4.4 集群容错

           略

5、Cache和EventBus中间件

5.1 Cache 中间件设计  

设计目标：

1. 将缓存服务器的部署配置与应用隔离，
2. 实现分布式，提高数据的均匀分布，并且能实现故障隔离
3. 根据KEY前缀的不同分配到MemoryCache 或者redis 上
4. 统计缓存的使用情况，便于分析和提高缓存合理资源的分配。

设计如下：

   

　　缓存中间件内部使用一致性哈希算法实现分布式。设置的虚拟节点能均匀分布。

　　缓存中间件暂时只实现Redis,MemoryCache做为缓存服务。后期应该会实现CacheBase

　　缓存中间件后期会提供配置服务，方便管理缓存服务配置，以及显示一些状态信息

 5.2 EventBus中间件设计

设计目标：

1. 基于发布/订阅的模式异步传递消息。
2. 集成第三方消息中间件，如：MSMQ,Rabbitmq
3. 实现基于发布/订阅的异步通知

设计如下：

          

        1.publisher: 是发布者把消息事件Event通过Event Bus 发布到Topic

        2.Event bus:：是事件总线，对于publisher 和 Subscriber 之间进行解耦，找到已经注册的事件订阅者，消息事件Event发送到topic

        3.Topic: 是消息路由，对于订阅者以广播的形式，让在线的Subscriber接收消息事件。

        4.Subscriber:是订阅者， 收到事件总线发下来的消息。即Handle方法被执行。注意参数类型必须和发布者发布的参数一致。

5、总结

          surging 0.0.0.1版本还有很多需要完善的地方，比如路由容错，服务降级、熔断，监控平台和配置服务平台，以及后续的第三方中间件的集成，这些任务都已经规划到日程，再不久的将来会看到1.0稳定版本的发布 ，如有兴趣可以加入QQ群：542283494

 

转载自:https://www.cnblogs.com/fanliang11/p/7191030.html

标签：异步,服务,隔离,通信,响应,surging,架构,剥析,请求
来源： https://www.cnblogs.com/bigmango/p/10392550.html