云平台的基础消息处理架构
我们身处在一个数字化商业的时代，作为一名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架构总体设计。
作者简介
臧一超，现任普元大数据产品线副总，基于微服务的企业架构实践者。十余年IT行业经验，专注于SOA、分布式计算、大数据处理、企业架构设计等领域。曾指导带领技术团队完成航天科工四院协同数据交换平台、上海移动ESB集成平台、华夏人寿服务治理平台等项目的系统实施以及方案撰写。