ESB架构,从支撑几千到百万订单的优化过程

ESB架构 , 从支撑几千到百万订单的优化过程背景说明2016年左右是SAAS快速发展的阶段 , 公司转型SAAS业务 , 变成了风口的猪 , 业务快速发展 , 同时也避免不了互联网公司的发展初期的痛点 , 技术严重拖了业务发展的后腿 , 几千的订单数已经让系统不堪重负 , 三天一个小故障 , 五天一个大故障 , 系统基本处于不可用的状态 。没有监控系统 , 基本都是客户发现问题电话打过来了 , 才知道系统出问题了 。
公司的技术栈是JAVA , 基于一个国外比较流行 , 国内比较冷门的开源ESB框架"Mule"来开发 , 当时公司决定做技术转型 , 将ESB往微服务转 , 同时选择GRPC作为微服务的开发框架 。
当时面临的问题是该领域的SAAS服务业务逻辑非常复杂 , 整个老的代码已经沉淀了一段时间 , 往新的框架迁移的时间周期比较长 , 所以老的代码还需要继续支撑一段很长的时间 , 但是业务量又高速发展 , 所以需要针对老的代码做性能优化 , 能够支撑到新的框架能够上线
架构介绍What is Mule ESB?Mule, the runtime engine of Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect Applications together quickly and easily, enabling them to exchange data. It enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web Services, JDBC, HTTP, and more. The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.

ESB架构,从支撑几千到百万订单的优化过程

文章插图
what-mule-esb.png
框架数据流转
ESB架构,从支撑几千到百万订单的优化过程

文章插图
数据流转.png
  • xxx-api是api层的服务;xxx-service是service层的服务 , ActiveMQ数据总线
  • routeQ:服务注册topic(service层服务注册具体的能力-方法) , 此处实现了一个服务注册发现的能力
  • API接收到请求:1、api从routeQ中获取请求具体实现的service层对应的队列名(xxx-service-{host1});2-api将消息(json格式)发送到对应的队列中;3-service层服务监听到队列的消息 , 进行业务处理;4、service层服务获取监听的消息中的target地址(xxx-api-{host}) , 将结果消息写会target地址;5、api服务监听到resp消息然后将结果返回给请求终端
  • api的处理是一个同步过程
服务部署架构图【ESB架构,从支撑几千到百万订单的优化过程】服务的部署主要是按照粗粒度的系统功能做了集群的划分:定时任务主要是
ESB架构,从支撑几千到百万订单的优化过程

文章插图
mule.png
  • 对外服务
主要是面向对外的服务 , 流量较大 , SLA要求比较高 , 出问题概率也比较高 , 系统故障的容忍度低
  • 内部管理服务内部运营和管理人员使用的 , 服务的SLA要求不高 , 系统故障容忍度高 , 允许一定时间的服务异常
  • 定时任务任务类的介于对外和对内的服务之间的SLA要求 , 由于也是服务于在线业务类的服务 , 部分服务实时性要求比较高 , 类似于准实时 , 比如延时的要求是秒级别的 , 所以这类的服务也需要有一定的可用性控制 , 系统故障荣任务略低
优化过程监控报警最开始没有监控报警 , 服务挂掉全是靠客户的电话才能知道 , 那么首先就是构建监控报警系统 , 基于小米开源的Open-Falcon构建了最早的监控报警系统 , 然后开始分析整个Mule开发框架的问题 , 通过分析部署图和Mule的框架可以得出 , 出问题最直接的表象 , 队列阻塞和队列的consumer数量异常 , 那么就是基于这个来实现一个报警 。
Mule基于ActiveMQ来作为自己的数据总线 , ActiveMQ是一个典型的AMQ , 类似于RabbitMQ、RocketMQ , 都有自己的admin管理页面或者api接口 , 那么就是基于admin-api来操作 , 由于ActiveMQ产品比较老 , 很多的协议还是基于XML , 那么就是通过接口获取队列的stat信息 , 然后分析队列的消息数量和consumer数量来触发报警 , Open-Falcon的开放性非常强 , 只需要写一个plugin就可以实现自己需要定制化报警


推荐阅读