阅读 1626

贝聊系统架构服务化之路

2015年3月,从网易BoBo离开,带着创业的情怀与期待,来到了贝聊。弹指间,已经过了快三年。在这三年的岁月里,贝聊后台系统架构经历了一个困难而又富有成就感的演变过程。

这个演变的过程,大致可分成几个阶段:技术平台替换阶段、服务化萌芽阶段、服务化形成阶段以及服务化发展阶段。

一、技术平台替换阶段

贝聊创业初期,后台系统架构是基于PHP技术平台的,由两个PHP开发人员维护。PHP技术平台,是大部分公司创业初期的首选。公司创业初期,业务复杂度低,用户量少,核心就是以尽量低的成本(人力成本、时间成本、技术成本与服务器成本)完成开发。

从2013年至2015年初,经过三年多的快速发展,原来基于PHP技术平台的配备(系统与人员)开始无法满足公司业务发展的需要了。随后,也就开始了JAVA技术平台逐步替换PHP技术平台这一阶段。

万事开头难,技术平台替换工作初期面临了很多困难。

首先,公司业务在快速发展,系统重构与业务需求迭代是并行的。前人说的:这相当于是给高速行驶的跑车换轮子,难度与风险可想而知。

其次,初来乍到的JAVA技术团队能行么?没有成果,还没有得到领导、同事的认可。

再次,原来的PHP技术团队能配合好工作么?重构系统相当于是要推翻他们原来负责的东西。

最后,JAVA技术团队对幼教行业缺乏了解,与网易BoBo的娱乐直播业务完全不同,是一个全新的业务领域。

面对这些困难,领导制订的技术平台替换策略是:新的业务系统采用JAVA技术开发,旧的业务继续在PHP技术上迭代,同时逐步采用JAVA技术进行重构、切换。

现在回想这一阶段的经历,记忆犹新。

新业务系统开发问题不大,重构的工作就头疼了。跟担忧的一样,PHP技术团队是有情绪的,沟通过程中大大小小的冲突不知道起了多少次。重构的过程中,线上业务大大小小的问题不知道出了多少回,因为责任的问题也不知道扯了多少次皮。加班、通宵、周末在家随时准备处理问题,都是常态。某天晚上因为身体不适请假提前回,发现“天还是亮的”,居然很不习惯。

还好,这一困难的阶段坚持下来了。到2016年初,基本(90%)完成了原有PHP技术平台系统的替换重构工作。这离不开领导的信任与包容,离不开JAVA技术团队的付出,也离不开PHP技术团队的配合与牺牲。这么多的困难最终都能解决,核心点在于大家目的是一样的:以公司发展为核心。

二、服务化萌芽阶段

技术平台替换阶段的重点是在保障业务正常迭代的情况下,确保系统重构与切换的平稳过渡,还没有充分考虑新系统架构的可拓展性与可维护性。

2016年3月,在公司完成B轮融资后,技术架构面临着无法满足产品线与技术团队规模快速扩大的风险。多个产品线,一堆开发人员,同时在仅有的几个应用上来开发,势必导致应用的业务越来越多、越来越臃肿。开发如何协作,版本如何管理,风险如何管控?搞不好就乱套了。

在对这些问题的思考中,进入了服务化萌芽的阶段。原来的架构如下图所示:


原来单个应用系统里集成了很多业务,多个应用系统存在重复业务,各个应用系统各自调用第三方服务(如短信、推送与IM等)。升级调整后的架构如下图所示:


这一阶段工作主要是公共服务的抽取与业务模块复用。比如将短信、推送与上传图片等抽取至一个公共的Web应用中,提供统一的REST API接口;同时,引入轻量级RPC框架Hessian,实现系统间的业务模块复用。

这样的架构存在两个明显的问题:一是REST API接口的调用方式效率不高,二是业务模块Hessian调用关系增多后难以管理。同时,在产品线与团队成员规模扩大的情况下,并不能很有效的解决上面提出的问题风险。

三、服务化形成阶段

2016年5月,引入了阿里巴巴的Dubbo分布式服务框架。全面开始对贝聊的系统业务进行分解重构,至2016年底,贝聊分布式服务化架构基本形成。架构如下图所示:


这一阶段,还引入了分布式配置中心Disconf(百度)与分布式任务调度系统Elastic-Job(当当)。至此,可以较好的解决产品线与团队成员规模扩大带来的问题了。业务服务组件新增与组合的灵活性,可以解决产品线增加的问题;而团队成员的增加,正是维护大量业务服务组件之所需。同时,基于DUBBO协议的接口调用方式,效率也比HTTP API方式要高很多。

至此,服务化架构基本成型,但同样也存在两个明显的问题:一是服务组件划分边界不清晰、服务组件间存在相互调用的关系;二是缺乏异常链路的监控机制。

四、服务化发展阶段

2017年初,重新思考了服务化组件划分与设计的问题。为了避免出现相互调用导致关系混乱的问题,将服务化组件分成两类:基础服务组件与业务服务组件。同时,制订了组件间的调用原则:只允许上层组件调用下层组件,确保调用的单向性。架构如下图所示:


2017年中,引入了大众点评的CAT(Central Application Tracking)异常监控项目,并于10月份完成所有应用系统的接入。CAT的接入实现了异常栈的监控与告警通知,这让很多BUG在用户反馈前已经被精确的发现、解决,极大的提升了用户体验与开发人员的成就感。

五、结语

2017年底,整个服务化架构终于是有了那么点样子。这里要感谢研发部每个兄弟的辛苦付出!不管是在贝聊的,还是已经离开贝聊的,SVN/GIT仓库里的项目代码都已经烙上了你们深深的印记(也留下了很多你们挖下的坑,哈哈)。未来还有很问题与困难在等着,贝聊研发部的兄弟们不要停止前进的脚步,让我们一起迎难而上。



感谢你们在贝聊的付出!
李欢与高西(PHP兄弟)、郑晓滨(研发部第2个员工)、林添瑞(研发部第4个员工)、李兴光(研发部第5个员工)、李海文、马玲、蓝国栋、江达贤、程健宇、李志锋、柯涪湘、邱俊、林宋勉


关注下面的标签,发现更多相似文章
评论