内容简介：贝聊系统架构服务化之路
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仓库里的项目代码都已经烙上了你们深深的印记（也留下了很多你们挖下的坑，哈哈）。未来还有很问题与困难在等着，贝聊研发部的兄弟们不要停止前进的脚步，让我们一起迎难而上。
感谢你们在贝聊的付出！
郑晓滨（研发部第2个员工）、林添瑞（研发部第4个员工）、李兴光（研发部第5个员工）、李海文、马玲、蓝国栋、江达贤、程健宇、李志锋、柯涪湘、邱俊、林宋勉
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- RPC架构之SOA服务化架构学习(一)
- 未来架构——从服务化到云原生
- 京东服务市场高并发下 SOA 服务化演进架构
- 分布式、服务化的 ERP 系统架构设计
- 互联网架构，究竟为啥要做服务化？
- 浅谈服务化和微服务化（上）
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
