哪里可以找到免费的网站,有动态图片的网站源码,asp.net 3.5网站开发实例教程,恶意 镜像网站1、前言
前面第一篇阐述了采用基于.NET CORE微服务架构#xff0c;应用surging服务端与客户端之间进行通信的简单示例以及对于surging服务化框架简单介绍。在这篇文章中#xff0c;我们将剥析surging的架构思想。
surging源码下载
2、通信机制
2.1 简介 在单体应用中应用surging服务端与客户端之间进行通信的简单示例以及对于surging服务化框架简单介绍。在这篇文章中我们将剥析surging的架构思想。
surging源码下载
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.网络问题常见的包括网络超时、网络闪断、网络阻塞等 都会导致微服务远程调用失败。 每个微服务都独立打包部署让服务之间进行进程隔离对于大型的互联网项目会有成百上千的微服务通常不会百分百独立部署对于同一业务的微服务会打包部署在一起对于时延非常敏感会合设在同一进程之内采用本地方法调用。
不同的微服务合设在同一进程中会产生以下问题
处理较慢的微服务会阻塞其它微服务某个微服务故障可能导致整个进程不可用
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的正比关系线程数量快速膨胀后系统的性能将急剧下降随着访问量的继续增大系统最终崩溃。
异步非阻塞I/O 通信 Surging 是基于Netty进行异步非阻塞I/O 通信即典型的请求/异步响应模式。此模式的优点如下
更好的吞吐量低延迟更省资源不再因过快、过慢或超负载访问导致系统崩溃 4.1.2 磁盘I/O 微服务对磁盘I/O的操作主要分为同步文件操作和异步文件操作 在Surging项目中需要从注册中心获取路由信息缓存到本地通过创建代理负载均衡算法选择Router路由信息的缓存到采用的是心跳检测的方式进行更新。 4.1.3 数据库操作 一般来说文件 I/O、网络访问乃至于进程间同步通信以及本节所讨论的 数据库访问等都较为耗时ado.netEntity 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 中间件设计
设计目标
将缓存服务器的部署配置与应用隔离实现分布式提高数据的均匀分布并且能实现故障隔离根据KEY前缀的不同分配到MemoryCache 或者redis 上统计缓存的使用情况便于分析和提高缓存合理资源的分配。
设计如下 缓存中间件内部使用一致性哈希算法实现分布式。设置的虚拟节点能均匀分布。 缓存中间件暂时只实现Redis,MemoryCache做为缓存服务。后期应该会实现CacheBase 缓存中间件后期会提供配置服务方便管理缓存服务配置以及显示一些状态信息 5.2 EventBus中间件设计
设计目标
基于发布/订阅的模式异步传递消息。集成第三方消息中间件如MSMQ,Rabbitmq实现基于发布/订阅的异步通知
设计如下 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群615562965
相关文章
谷歌发布的首款基于HTTP/2和protobuf的RPC框架GRPC拥抱.NET Core跨平台的轻量级RPCRabbit.Rpc基于DotNet Core的RPC框架(一) DotBPE.RPC快速开始基于.NET CORE微服务框架 -surging的介绍和简单示例 开源
原文地址http://www.cnblogs.com/fanliang11/p/7191030.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
