剥析surging的架构思想

1、前言

 

前面第一篇阐述了采用基于.NET CORE微服务架构，应用surging服务端与客户端之间进行通讯的简单示例以及对于surging服务化框架简单介绍。在这篇文章中，咱们将剥析surging的架构思想。

surging源码下载

二、通讯机制

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机制，客户端向服务端发送请求，服务端处理请求，异步响应，客户端不会由于等待服务返回而阻塞其它请求。

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

三、部署和调用

1.单体应用架构

当网站流量很小时，只须要将全部功能部署在一块儿，以减小部署节点和成本

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

 

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

 

2.垂直应用架构

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

 

3.分布式微服务架构

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

而Surging 微服务采用分布式集群部署方式，服务的消费者和提供者一般运行在不一样的进程中，进程之间通讯采用RPC方式调用，它的工做原理以下：

                                                                         图1-2 Surging分布式RPC调用

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

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

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

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

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

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

三、整体架构

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

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

四、分布式的可靠性

      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 集群容错

           略

五、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方法被执行。注意参数类型必须和发布者发布的参数一致。

五、总结

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