soa纵向和横向设计

最近一直在考虑把soa相关的思想整合一下,让soa的纵向横向设计都形成闭环,也可以看看哪些方面需要补足。

soa的纵向是我之前一直努力的方向,虽然因为工作原因拖延了一阵子,但接下来会有比较充足的时间在这方面做更深入的思考。

所谓的“纵向”是什么意思?可以理解为单体进程中与soa化相关的东西。纵向设计一般收益比较快,技术深度也相对较高,涉及到:

  • rpc框架选择:涉及到endpoints之间使用什么协议,协议的选择是有tradeoff的,大部分rpc协议传输数据依赖tcp协议,有使用http1.1的、有自研的、有使用http2的,协议本身的复杂度和设计倾向会严重影响框架本身的设计难度,大部分情况我们关注的还是框架自身的上手难度和框架的性能。当前公司我们选择的是关注度比较高的grpc-go,第一点满足,但是框架的性能上,业务逻辑简单的情况下单进程支持上w的qps是没有问题的,但有grpc-go处理耗时有个在ms级别波动的问题,这个问题需要处理掉,才敢大规模使用。
  • 基础库封装:单纯的rpc框架只要做好上述两点就着实不易了,如果rpc框架的野心不止于此,想要把用户的业务逻辑日常开发也考虑进来,那么就要围绕用户的业务逻辑提供基础库。基础库本身和rpc框架并没有绝对关系,当然基础库可能使用rpc框架的对外API封装一些共用的与请求处理相关的东西。基础库是什么?业务逻辑通常情况下是用户进程使用第三方数据服务(例如:存储/cache/mq)进行产品需求实现的源代码,业务逻辑对接的服务方是有限的,一般就mysql、redis、http、mq、es、或者其他rpc服务,我们针对这些应用场景,提前为rd选择好与第三方服务对应的sdk,将sdk进行二次封装后,集成到rpc项目的构建过程中,“集成”不能简单的认为是lib库做好,rd可以选择使用就行了,这谈不上集成,只是放在那而已。放在那,并且好用是第一步,为了进一步提升rd效率,我们要规范化/统一使用库的方法,这块会进一步提升开发效率。
  • 入口:rd有了,框架+基础库都有了,现在rd要着手开始做一个soa服务,不能rd按照自己意愿随意拿过来用,我们需要提供一个工具,让每个项目的初始状态都是一致的。

在我做了上述所有工作之后,有一个点一直没有深入dig,现在我的工具生成的代码已经侵入到用户项目中,这样是否存在问题,我觉得只要保证两点就算侵入一些也没关系:

  • 生成后代码要与rd相关的业务逻辑相关:不相关就是框架和基础库,这些需要以另一种方式集成进来,就是第三方lib库,不能说lib库的更新是rd通过工具拉下来的,应该是rd选择性升级lib库才可以。
  • 生成代码的规则不能变,设计完成后,只能扩展并保持向后兼容,否则对用户的创伤不可避免。

之前做的构造工具通过上面的讨论,看样子还是有特别多需要重构和约束的地方,要做框架最重要的可能就是克制。

soa的横向是我接下来将要探索的新东西,“横向”可以理解为与单个rpc进程同等地位的支撑平台。

单个rpc进程能提供服务,但如果没有集中的管理,rpc进程的数量会在无意识的情况下爆炸,并且再难以约束,到处可能有死掉的rpc进程,rpc服务之间的关系也异常难以梳理(各种老旧wiki能把你烦死),rd之间的服务调用完全靠口头传递以及过期并且难以搜索到的wiki来维持,所以单个rpc进程是需要被约束,需要被监控,需要能被下线或废弃。

上面描述了为什么没有支撑平台不行,那么有了支撑平台是不是还有附加优点。soa框架试图在单个业务项目的开发方法和机制上达成共识,而支撑平台试图在进程关系和策略管理上达成共识。同时平台作为管理rpc进程的统一入口,和上面描述的构建工具是类似的,rpc进程的管理方式上达到统一,不仅可以在将来的服务交互上有共同的术语,也标准化了工作方法,让所有工作流程都规范化。

下面具体聊聊,soa支撑平台初始阶段要包含哪些具体的功能:

  • 服务发现和注册,单体rpc进程是通过该功能参与到自己所属网络的交互中,类似arp吧,就是把自己的信息告诉别人,并获取自己想要知道的东西。
  • 配置服务,和上一点结合做,可以推动rd尽量将机制和策略分开,动态的管理自己的进程。
  • 管理平台,一提后台,后端开发工程师都有种干呕的感觉,不过平台不可或缺,就是rd日常维护自己服务的地方。这块功能点的体量巨大,下面单独聊。
  • 周边服务,要rd更爽,创建/管理/上线流程(对接现有op平台),日志(收集/监控/查看对接EFK)、监控(qps/耗时/自定义对接hubble)。
  • 稳定性监控,这块单独拿出来说,集中式管理的目的很大的原因是,架构部门对于rd上线的进程可能收集信息并做一些统计。例如:机器资源占用不够(收敛机器)、应用的qps和耗时波动大(异常通知)、单体应用需要的关注程度(以op角度来看就是访问量/机器的使用是否快要达到瓶颈)。可以想想公司的所有rpc服务编织成了一张巨大的网,但每个应用依赖的基础服务都在我们手里。我们知道所有事情,除了业务bug外。
soa纵向和横向设计
Share this