独家系列:让咱们碰见将来——为何选择SEDA做为云平台的基础消息处理架构(PPT)

本文为普元软件产品部大数据产品线副总臧一超在普元云计算架构设计群的微课堂分享,转载需与本号联系,欢迎关注EAII(微信公众号:eaworld)。web


普元新一代数字化企业云平台研发设计群,将公开普元研发和设计过程并直播架构设计与讨论及相关PPT素材。如需加入此群请直接回复此公众号:“加群 姓名 公司 职位 微信号”。算法



咱们身处在一个数字化商业的时代,做为一名IT工做者,如何保证咱们所设计的系统、开发的服务在面对复杂不肯定的网络环境中,还要去交付准确可靠稳定的服务?编程


咱们在数以千计微服务支撑的云计算平台下,怎么考虑不肯定性的并发请求、超量请求、请求的不断积压?微信


同时,咱们还要兼顾外部所链接的商业功能网络中断、服务不可用、服务超时、事务完整性等等一系列的问题。那么,如何来解决现实世界中的这些问题呢?网络



传统的并发编程模型主要有两种:一种是Thread-based concurrency, 另外一种是Event-driven concurrency。多线程



总结下两种模式的特色,
架构


基于线程的并发:每一个任务一线程直线式的编程使用资源高昂,context切换代价高,竞争锁昂贵,太多线程可能致使吞吐量降低,响应时间暴涨;并发


基于事件的并发:单线程处理事件的每一个并发流实现为一个有限状态机应用直接控制并发负载增长的时候,吞吐量饱和响应时间线性增加。框架


SEDA架构是目前云计算、微服务时代下一种优秀的消息处理架构,并且历经考验,稳定可靠。异步



SEDA架构的核心思想:把一个请求处理过程分红几个Stage,每一个Stage可由不一样的微服务进行处理,不一样资源消耗的Stage使用不一样数量的线程来处理,微服务之间采用异步通信的模式。


时代在变,咱们的技术架构也在变,顺时针看架构的以下演进过程:



应用逻辑封装到Event Handler,接收到许多事件。处理这些事件,而后派发事件加入其余Stage的queue。对queue和threads没有直接控制Event queue吸纳过量的负载,有限的线程池维持并发。


Stage控制器:负责资源的分配和调度;控制派发给Event Handler的事件的数量和顺序;Event Handler可能在内部丢弃、过滤、重排序事件。



接下来,说一下这种架构里的动态资源控制器,一个是线程池管理,另外一个是批量管理。


线程池管理器决定了每一个微服务处理下的Stage合理的并发程度,经过观察队列长度,超过阈值就添加线程并移除空闲线程。



SEDA架构中SEDA并发模型依赖于Event-driven concurrency模型来支持高并发。利用一组线程来处理每一个请求,而不是每个请求一个线程,利用Nonblocking I/O来避免资源的阻塞。



它的核心是,全部的逻辑处理以及接入、接出所有进行隔离,根据不一样的业务操做类型分别对待合理进行分组。实际上,基于微服务架构的云平台在实现这一理念的时候有先天性的优点。



SEDA框架根据业务系统可靠性要求、消息框架能够采用内存队列或者持久化队列,知足不一样SLA要求下的可靠性保障。



SEDA架构下提供服务宿主处理的容器,容器是服务运行的基础环境,容器负责资源分配管理、服务超时管理、服务流量控制、服务路由控制。



每一个容器有2组channel(每组有请求、响正常应、错误响应)组成,根据是否具备输入、输出,容器分为三种类型。


接下来,咱们来看看容器的路由。



做为独立的stage,channel根据不一样业务负载提供路由,根据路由规则和服务元数据对服务进行路由。路由提供本地路由及远程路由能力,支持服务的横向扩展。


为了支撑远程路由,须要平台提供分布式的调度框架能力支撑,一个简化的分布式调度框架以下:



容器提供资源管理能力,对服务性资源、对象资源提供池化调度能力,精确匹配服务请求量。



在这种架构下,咱们能够很方便的对云环境下的微服务(商业功能)实现多种控制、保障机制。
举个例子:分布式云环境下的流量控制机制在SEDA架构下的实现。




最后给你们奉上云平台下基础消息处理架构的SEDA架构整体设计:







附: 各 群 答 疑


Q一、群友1:普元的技术架构强调容器和统一资源调度吗?怎么解决跨云的微服务高可用,弹性伸缩,服务框架跨DC的RPC问题?如今不少密集计算的平台都会考虑基于容器,这样能够和mesos配合解决弹性和容量的问题。


答:没有强调容器,调度是必不可少的。容器只是给弹性伸缩提供了基本的可能性,关键是包括无状态、分布式的设计,才能真正解决弹性和容量。mesos侧重资源调度,是个好东西。不过咱们如今作的简单,只用了k8s。(普元产品部主任架构师顾伟)


群友2:高性能路由器里QOS的算法能够参考。

群友1:简化是最重要的,初期能够跳过mesos直接k8s,后期仍是建议通用mesos.


答:恩,一种是QOS的算法以解决通讯,还有业务双活的一些作法,尽量减小跨数据中心调用。(普元产品部主任架构师顾伟)


Q二、群友:这个架构的产品形态和用户界面是什么?

答:架构的自己就是分布式可伸缩的,任何须要高可靠、高可用、海量消息、事件处理的商业功能均可以使用它。它做为云计算下的一种基础服务,也能够做为云计算微服务架构下的消息处理服务。(普元大数据产品线副总臧一超)


如需加入EAII研究院成为会员请点击此公众号菜单:EAII-在线注册或添加微信号:elaineyuan928。


关于做者:

臧一超

EAII-企业架构创新研究院 专家委员

现任普元大数据产品线副总,基于微服务的企业架构实践者。十余年IT行业经验,专一于SOA、分布式计算、大数据处理、企业架构设计等领域。曾指导带领技术团队完成航天科工四院协同数据交换平台、上海移动ESB集成平台、华夏人寿服务治理平台等项目的系统实施以及方案撰写。


关于EAII

EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,是专一于企业架构与业务创新领域的研究机构,致力于金融、电信、能源与政务等行业领域的企业软件架构优化设计与 创新研究,以及分布式计算、服务构件技术、可视化技术、业务流程管理、内存计算、企业移动计算、数据治理等领域的技术研究。


eaworld项目(微信号:eaworld,长按二维码关注)


eaworld是EAII的官方微信帐号。


↓↓↓阅读原文,下载课件!

本文分享自微信公众号 - EAWorld(eaworld)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索