独家系列：让我们遇见未来——为什么选择SEDA作为云平台的基础消息处理架构（PPT）

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

普元新一代数字化企业云平台研发设计群，将公开普元研发和设计过程并直播架构设计与讨论及相关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架构总体设计：

附： 各 群 答 疑

Q1、群友1：普元的技术架构强调容器和统一资源调度吗？怎么解决跨云的微服务高可用，弹性伸缩，服务框架跨DC的RPC问题？现在很多密集计算的平台都会考虑基于容器，这样可以和mesos配合解决弹性和容量的问题。

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

群友2：高性能路由器里QOS的算法可以参考。
群友1：简化是最重要的，初期可以跳过mesos直接k8s，后期还是建议通用mesos.

答：恩，一种是QOS的算法以解决通信，还有业务双活的一些做法，尽可能减少跨数据中心调用。（普元产品部主任架构师顾伟）

Q2、群友：这个架构的产品形态和用户界面是什么？

答：架构的本身就是分布式可伸缩的，任何需要高可靠、高可用、海量消息、事件处理的商业功能都可以使用它。它作为云计算下的一种基础服务，也可以作为云计算微服务架构下的消息处理服务。（普元大数据产品线副总臧一超）

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

关于作者：

臧一超

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

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

关于EAII

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

eaworld项目（微信号：eaworld，长按二维码关注）

eaworld是EAII的官方微信账号。

↓↓↓阅读原文，下载课件！