贝聊系统架构服务化之路

内容简介：贝聊系统架构服务化之路

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

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

一、技术平台替换阶段

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、结语

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

感谢你们在贝聊的付出！

郑晓滨（研发部第2个员工）、林添瑞（研发部第4个员工）、李兴光（研发部第5个员工）、李海文、马玲、蓝国栋、江达贤、程健宇、李志锋、柯涪湘、邱俊、林宋勉

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• RPC架构之SOA服务化架构学习(一)
• 未来架构——从服务化到云原生
• 京东服务市场高并发下 SOA 服务化演进架构
• 分布式、服务化的 ERP 系统架构设计
• 互联网架构，究竟为啥要做服务化？
• 浅谈服务化和微服务化（上）

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。