首页 > 业界 > 技改之路:从单块应用到微服务,我的血泪总结
2016
08-31

技改之路:从单块应用到微服务,我的血泪总结

  技改是技术改造的简称,是技术的蜕变。本文指的是在公司技术发展的某个瓶颈阶段,按原有开发和组织方式已经无法玩下去,这时公司希望引进架构师或技术牛人,来破解当前困局。技术改造,对于公司和技术人员而言都非常难得,参与者多,主导者少。我有幸前后主导过 3 次 OTA 系统的技改,规模有大有小,每次环境和问题虽不一样,但还是有套路可循。

  《技改之路》少讲技术多讲路,我们不过多的关注技术细节和中间件的实现,而重点讲述技术改造的过程和思考,以下是本次分享的 Topic:

  • 系统背景
  • 前期工作
  • 技改实施
  • 总结

  一、系统背景

  1、技术规模

  公司

  • 国内领先的 B2B 机票分销平台
  • 资本原始积累,财务良好,一直盈利

  系统规模

  • 200+ 应用
  • 100+ 库,1 万+表

  研发规模

  • 开发人员 200 人左右
  • 服务器有 200 台左右

  此案例是一个中等规模的电子商务公司,老板白手起家,资本原始积累,现在赚钱的互联网公司很少哦。公司从 2006 年的几个研发人员,到技改前的 200 个左右研发人员,业务发展良好,是国内领先的 B2B 机票分销平台,互联网名声虽不大,但处于闷声发大财的状态。

  公司之前尝试过 2 次系统重建,请了一批批的牛人,前后经历过 4 年。公司消耗大,但都以失败告终。此案例是我本人的第 2 次技改,效果不错,整体进展顺利,团队技术水平也有1~2 个档次的提升,算是比较成功的实践。另外,因为案例过于真实,有些 UML 会打上马赛克,请多谅解。

  2、单块应用

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 1

  3、主要问题

  • 单块应用,该合并的没有合并,该拆开的没有拆开,单个体量不合理,主平台体量太大,其它又过小;
  • 技术过旧:使用 7 年以前的技术,主平台采用单块应用,且体量过大,无法整体更新维护;
  • 多版本共存:版本混乱,只敢添加,不敢修改;
  • 整个系统非常脆弱,问题多,访问量一大就挂;
  • 管理问题:发布困难、测试困难、修改困难、排错困难。

  二、前期工作

  1、架构部组建

  成立架构部:

  • 内招几名老程序员,外招几个架构师

  培养:

  • 内部走出去,提高眼界;外部牛人请进来,落地了解历史和业务

  制度:

  • 项目管理+知识分享: JIRA+WIKI
  • 团队建设、技术分享、工程师文化

  2、总体规划

  架构是演化出来的还是设计出来的?对于创业场景,创业本身就是在未知中寻找机会,将不清楚变为清楚,系统的架构自然是演化出来的,而对于技术改造或 Google 搜索等复杂工程场景,系统的架构当然要精心策划。

  公司电商系统总体架构,我们整整花了 1 个多月的时间,对项目做了总体的规划,然后对内宣讲推广,让每一个参与者了解自已的目标和价值。不手握地图,你怎知站对了位置!

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 2

  3、中间件构建

  我们构建的中间件有:

job/redis/center Log/业务监控 metrics/dashboad/调试工具 windbg/rabbitMQ/ORM 工具 dapper/MongoDB/jetermclient/公共类库

jFX/zookeeper/openTSDB/HBase/searcher 工具 solr/元数据管理 DDM/DLL 管理 nuget/自动发布 Jenkins/微服务架构 JSOA/

  中间件是应用系统的基础设施,是应用的装备和工具。农村建住房是一块砖一块砖的往上垒,城市建大 house 则是先打地基,然后再建主框架,最后才是垒砖,所以中间件的建设是大中型系统建设的前提。

  以上中件间的构建过程贯穿于整个技改的生命周期,每一个中间件可能需要花1~2 个月,它们大部分都基于开源。请关注上面的顺序,直面当前的问题,按需快速构建和推动。虽然使用开源,但中件间的引进和改造有自已的一套流程:调查 => 试用 => 选型 => 深入研究 => demo => wiki => 分享推广 => 业务系统试用 => 改进完善 => 大规模推广。

  中间件的构建和增加,不仅对当前业务系统影响较小,还可以解决一部分业务难题,减轻数据库的压力。同时它还有利于建立技术氛围和分享机制。一支有激情、爱技术的研发团队,对技改的具体实施是非常重要的。

  三、技改实施

  1、数据库改造

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 3

  当面对 100 个多库时,我认为系统架构师关注到数据库级别即可,建库拆库。数据库按模块整体迁移,其实并没有想象中那么难,理想情况下只需修改数据库的链接,而对于表和字段的优化,可由应用架构师或技术主管,以 SOA 收口或应用重构来实现。

  数据库如何做到可伸缩,可大可小方便拆分呢,思考如下:

  1. 上图从内往外看,一个框即可以是一个库,也可以是一个模块,还可以是一个表,根据当前业务规模和系统复杂度来实现;

  2. 我们的大实体关系图具体为:产品、用户、订单、结算、基础设施。它们早期可以是一个库,里面有 5 个模块,中期可以分为 5 个库,后期则可以更底级别分为更多的库;

  3. 命名规范:数据库名:业务线缩写+库名;模块名:参考大E-R 图+专业词汇缩写;表名:模块缩写+表名;自增编号:表名 +ID;

  4. 模块内可多表联接,模块间减少联接,数据库间不允许联接;

  5. 每一个数据库有且仅有一个 Owner 组,原则上只允许一个团队才能 Create,其它团队访问需要分级控制,L1 为接口,L2 为只读库,L3 为直接读写“写库”。

  数据库规划

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 4

  数据库是整个信息系统中生命周期最长、最难修改的部分。所以让时间来解决时间的问题,要加强设计,具体实施过程如下:

  1. 在地图即总体架构文档推广后,我们就新建立了一批库,这在早期还遭到 DBA 的抱怨;

  2. 新增相关库后,新表按新规则创建,特殊情况走特珠审批;

  3. 去 SP 去关联,让数据库减少计算,回归存储本质;

  4. 数据库拆分,改表改字段,采用模块整体迁移或应用重构;

  5. 一年后,再去看数据库,发现在没有特别立项和驱动的情况下,已接近一半的表在新库中。

  数据变迁

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 5

  状态图是数据的变迁,是数据与行为的互动,数据的变化会引起行为的变化,行为的变化会产生数据的不同。上图是国内的订单状态变迁图,它的价值不仅属于数据库层,还在于 SOA 服务化和核心业务流程。

  2、服务改造

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 6

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 7

  服务是动词,是行为或活动的抽象,它的价值在于业务逻辑或行为的重用,具体实施过程如下:

  1. 服务列表和服务协议,在设计阶段使用 Excel 表格;

  2. 统一 Request/Response 规范;

  3. 服务实现,因没有直接可见的业务价值输出,最好以工单或项目来落地;

  4. 服务治理,早期没有工具时,使用 WIKI 做简单管理,后期使用专业的服务治理工具。

  领域模型

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 8

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 9

  没有领域图的架构设计都是耍流氓,我们画领域图的架构师是 2 位老员工,没有多少高大上,甚至于他们之前没有画过 UML,但我们的状态图和领域模型都是出自他们之手。其实画领域图的关键是懂事物本身,并知道它们的关系。我们的领域图与业务模型中的 5 大业务流程一一对应,包括:预订流程,订单处理流程,产品供应流程,财务结算流程,账户管理流程。

  微服务

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 10

  我们的微服务 JSOA V2.0 是基于 ServiceStack 当时最新的版本号 4.0.50 实现的,它本身支持轻量级协议和 Metadata,以及 Swagger,是微服务的一种架构实现。另外,它还可以再扩展以 API Gateway 的方式实现 Open API。

  微服务 MSA 与我们之前的 SOA、ESB 有什么区别呢?

  • ESB 有总线和聪明的管道管理能力;

  • SOA 弱化了中间的管道和总线,强化了两端;

  • 微服务 MSA 使用通用的轻量级协议和更加 web 化(RESTFUL)。

  3、应用架构改造

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 11

  系统是什么?系统=元素+关系。应用架构是什么?应用架构=应用+架构。应用就是系统的最小单元,应用分级和应用编号则构成了应用关系即应用的架构,它有利于应用的管理、交互和追踪。应用分为产品线,子系统和应用 3 级,每一级编号为 2 位,如 100206。应用要从用户的视角出发,先有用户,然后有应用功能,这样才是以用户为中心去构建系统。

  4、组织架构微调

技改之路:从单块应用到微服务,我的血泪总结 - 同创卓越 - 12

  组织架构没有最佳实践,只有适合于自已当前的选择,以下是组织架构与技术架构对齐方面的思考:

  1. 艺术与工程相关分离:UED;

  2. 软件开发与硬件相分离:运维;

  3. 技术研发与业务研发相分离:架构部;

  4. 需求,实施,验收相分离:每业务线分产品组、开发组、测试组;

  5. 开发按业务职责相分离:预订组、产品组、订单组;

  6. 专业技术委员会制:测试、产品、开发、轮流主持,设委员长;

  四、总结

  1、过程总结

  第一步总体规划:手握地图,明确路线;

  第二步数据库:建库拆库,去 join 去 SP;

  第三步中间件:按需构建,先增加常用;

  第四步服务:技改=工单,有业务价值输出;

  第五步应用:拆应用,建门户 Portal,重构应用;

  第六步组织架构微调:组架技术与组织架构对齐,技改之后调整;

  第七步固化:框架化,自动化,管理过程工具化如 DevOps。

  2、经验感悟

  • 从服务入手是错的,从数据库或中间件入手是正确的。服务属于高级阶段,方便行为的重用,是深层次优化,但太慢了;

  • 从当前问题或故障入手,要先灭火,逆向分析 dump 工具很重要;

  • 历史要尊重,早期不可做大的改动,不能过多地影响现有业务。建议只做加法,建新库和新中间件,这样就不会有太多阻力和负担;

  • 一般不能全部重建,除非系统较小,系统规模大时只能拆分后分步重构;

  • 技术并不是技改过程中最复杂的,人和事及关系才是麻烦的部分,历史问题的后面是人;

  • 每次环境和问题都不一样,要有准备脱一层皮的心态。

  3、通盘无妙招

  技改是大折腾,于公司于个人而言都是,小改怡情,大改伤身,我们应该避免大的技术改造,但此现象又比较常见,特别是业务发展快的创业公司。所以真正高手下棋,应该是通盘无妙招,让正确的事情很容易发生,基于自然的演化来实现技术的演进。

  怎样才能通盘无妙招,系统良性长久的发展?我们需要两个力量,一个是技术,一个是业务,如果只重视业务,而很容易在技术上积劳成疾,如果完全技术驱动,则又容易忘记业务目标。所以它们应该相伴相生,共同发展,在大的技术改造实施之后,在框架和流程相对固化后,小的技术重构项目应该长期存在,这样才能良性循环,让系统进入自然演进的状态。

  互动问答

  问题:请问张老师如果再来一次技改你会怎么做?在你做过的技改过程中你觉得你最大的收获是什么?觉得做的不好的又是什么?

  这个问题非常好,为了更好回答您的问题,我简单介绍一下本人的 3 次技改经历。我的第 1 次技改是重建,项目从 10 月份到第二年 8 月,历史 10 个月,可以说是技术成功项目失败。第 2 次技改是重构,只管技术,少管人和业务,整体效果好,可以归结为成功。第 3 次技改还是重构,既管技术又管人,且业务处于高速发展期,资源少,可以总结为技术与业务相伴相生,技术效果一般。

  如果以后还有机会,自已就不再直接负责了,实在是太累,从内外各招几个架构师,并按上面的工作流程和方式,然后把握好技术与业务的关系和资源占用即可。回到具体问题:

  1. 如果再来一次,我会多参考第 2 次技改经验,即 PPT 分享的过程总结;
  2. 技改后的收获是脱胎换骨,技术和管理都有很大提升;
  3. 不好的地方:要更多的关注业务,以及平衡好业务与技术的关系。

  问题:单块应用向微服务迁移时,平滑过渡有什么技巧?如何解决分布式事务一致性呢?还有关于微服务持续交付、测试、监控(语义监控)方面有落地工具吗?

  1. 平滑过渡的技术:直面当前系统的问题,不断有价值输出,然后参考上面的过程总结,先规划,然后中间件和数据库,最后是服务和应用;
  2. 分布式事务一致性:使用替代方案,如最终一致;
  3. 落地工具:MSA 与 SOA 的治理没有本质差别,还是 DevOps/Trace/Metrics/,我们使用的是 ServiceStack/JMetrics/CenterLog/Jenkins/。

  问题:如果旧有模块关联复杂,又影响现有系统性能,相关开发人员流失,不好梳理,改造有风险,重写老板不答应,该如何取舍呢?

  1. 旧有模块关联复杂,又影响现有系统性能:先灭火解决当前故障, 逆向分析 dump 工具;
  2. 相关开发人员流失:引进中件间,建立分享机制和学习型团队,讲技改总体规划,让每个人了解自已的价值和目标;
  3. 不好梳理,改造有风险:内招几个老员工成为应用架构师;
  4. 重写老板不答应:有业务价值输入,技改==工单或项目,借助业务项目来实现技改。

  嘉宾介绍

  张辉清,中青易游 CTO,曾先后就职于广之旅、携程商旅架构、古大集团,在古大集团主导了从单块应用到微服务的技术改造,任首席架构师和高级技术总监,目前就职于中青实业下属公司中青易游,任职 CTO。国家系统分析师和高级项目管理师,12 年的互联网分布式系统研发和架构经验,10 年的 OTA 旅游行业经历,是一枚技术爱好者和旅游爱好者。 

来自: InfoQ
 
最后编辑:
作者:同创卓越
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。