<p>“</p>    <p>技改是技术改造的简称，是技术的蜕变。技术改造，对于公司和技术人员而言都非常难得，参与者多，主导者少。我有幸前后主导过3次OTA系统的技改，规模有大有小，每次环境和问题虽不一样，但还是有套路可循。</p>    <p>《技改之路》少讲技术多讲路，我们不过多的关注技术细节和中间件的实现，而重点讲述技术改造的过程和思考，以下是本次分享的Topic：</p>    <ul>     <li> <p>系统背景</p> </li>     <li> <p>前期工作</p> </li>     <li> <p>技改实施</p> </li>     <li> <p>总结</p> </li>    </ul>    <p><em>1</em></p>    <p><strong>系统背景 </strong></p>    <p>1、技术规模</p>    <p>公司</p>    <ul>     <li> <p>国内领先的B2B机票分销平台</p> </li>     <li> <p>资本原始积累，财务良好，一直盈利</p> </li>    </ul>    <p>系统规模</p>    <ul>     <li> <p>200+应用</p> </li>     <li> <p>100+库，1万+表</p> </li>    </ul>    <p>研发规模</p>    <ul>     <li> <p>开发人员200人左右</p> </li>     <li> <p>服务器有200台左右</p> </li>    </ul>    <p>此案例是一个中等规模的电子商务公司，老板白手起家，资本原始积累，现在赚钱的互联网公司很少哦。公司从2006年的几个研发人员，到技改前的200个左右研发人员，业务发展良好，是国内领先的B2B机票分销平台，互联网名声虽不大，但处于闷声发大财的状态。</p>    <p>公司之前尝试过2次系统重建，请了一批批的牛人，前后经历过4年。公司消耗大，但都以失败告终。此案例是我本人的第2次技改，效果不错，整体进展顺利，团队技术水平也有1~2个档次的提升，算是比较成功的实践。另外，因为案例过于真实，有些UML会打上马赛克，请多谅解。</p>    <p>2、单块应用</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8025d3f5543bc84cdca17be3ae75259d.jpg"></p>    <p>3、主要问题</p>    <ul>     <li> <p>单块应用，该合并的没有合并，该拆开的没有拆开，单个体量不合理，主平台体量太大，其它又过小；</p> </li>     <li> <p>技术过旧：使用7年以前的技术，主平台采用单块应用，且体量过大，无法整体更新维护；</p> </li>     <li> <p>多版本共存：版本混乱，只敢添加，不敢修改；</p> </li>     <li> <p>整个系统非常脆弱，问题多，访问量一大就挂；</p> </li>     <li> <p>管理问题：发布困难、测试困难、修改困难、排错困难。</p> </li>    </ul>    <p><strong>前期工作 </strong></p>    <p>1、架构部组建</p>    <p>成立架构部：</p>    <ul>     <li> <p>内招几名老程序员，外招几个架构师</p> </li>    </ul>    <p>培养：</p>    <ul>     <li> <p>内部走出去，提高眼界；外部牛人请进来，落地了解历史和业务</p> </li>    </ul>    <p>制度：</p>    <ul>     <li> <p>项目管理+知识分享： JIRA+WIKI</p> </li>     <li> <p>团队建设、技术分享、工程师文化</p> </li>    </ul>    <p>2、总体规划</p>    <p>架构是演化出来的还是设计出来的？对于创业场景，创业本身就是在未知中寻找机会，将不清楚变为清楚，系统的架构自然是演化出来的，而对于技术改造或Google搜索等复杂工程场景，系统的架构当然要精心策划。</p>    <p>公司电商系统总体架构，我们整整花了1个多月的时间，对项目做了总体的规划，然后对内宣讲推广，让每一个参与者了解自已的目标和价值。不手握地图，你怎知站对了位置！</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/e3f0a75b28180de2cf108a636a2160f2.png"></p>    <p>3、中间件构建</p>    <p>我们构建的中间件有：</p>    <p>job / redis / center Log /业务监控 metrics / dashboad /调试工具 windbg / rabbitMQ / ORM 工具 dapper / MongoDB / jetermclient /公共类库 jFX / zookeeper / openTSDB / HBase / searcher 工具 solr /元数据管理 DDM / DLL 管理 nuget /自动发布 Jenkins /微服务架构 JSOA /</p>    <p>中间件是应用系统的基础设施，是应用的装备和工具。农村建住房是一块砖一块砖的往上垒，城市建大house则是先打地基，然后再建主框架，最后才是垒砖，所以 <strong>中间件的建设是大中型系统建设的前提。</strong></p>    <p>以上中件间的构建过程贯穿于整个技改的生命周期，每一个中间件可能需要花1~2个月，它们大部分都基于开源。请关注上面的顺序，直面当前的问题，按需快速构建和推动。虽然使用开源，但中件间的引进和改造有自已的一套流程：调查 => 试用 => 选型 => 深入研究 => demo => wiki => 分享推广 => 业务系统试用 => 改进完善 => 大规模推广。</p>    <p>中间件的构建和增加，不仅对当前业务系统影响较小，还可以解决一部分业务难题，减轻数据库的压力。同时它还有利于建立技术氛围和分享机制。一支有激情、爱技术的研发团队，对技改的具体实施是非常重要的。</p>    <p><em>3</em></p>    <p><strong>技改实施 </strong></p>    <p>1、数据库改造</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/7a072e4fc83d62bfb44cc327d10a3a8f.jpg"></p>    <p>当面对100个多库时，我认为系统架构师关注到数据库级别即可，建库拆库。数据库按模块整体迁移，其实并没有想象中那么难，理想情况下只需修改数据库的链接，而对于表和字段的优化，可由应用架构师或技术主管，以SOA收口或应用重构来实现。</p>    <p>数据库如何做到可伸缩，可大可小方便拆分呢，思考如下：</p>    <ol>     <li> <p>上图从内往外看，一个框即可以是一个库，也可以是一个模块，还可以是一个表，根据当前业务规模和系统复杂度来实现；</p> </li>     <li> <p>我们的大实体关系图具体为：产品、用户、订单、结算、基础设施。它们早期可以是一个库，里面有5个模块，中期可以分为5个库，后期则可以更底级别分为更多的库；</p> </li>     <li> <p>命名规范：数据库名：业务线缩写+库名；模块名：参考大E-R图+专业词汇缩写；表名：模块缩写+表名；自增编号：表名+ID；</p> </li>     <li> <p>模块内可多表联接，模块间减少联接，数据库间不允许联接；</p> </li>     <li> <p>每一个数据库有且仅有一个Owner组，原则上只允许一个团队才能Create，其它团队访问需要分级控制，L1为接口，L2为只读库，L3为直接读写“写库”。</p> </li>    </ol>    <p><strong>数据库规划</strong></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9f11ed99300688c54c4f09ec721c9884.png"></p>    <p>数据库是整个信息系统中生命周期最长、最难修改的部分。所以让时间来解决时间的问题，要加强设计，具体实施过程如下：</p>    <ol>     <li> <p>在地图即总体架构文档推广后，我们就新建立了一批库，这在早期还遭到DBA的抱怨；</p> </li>     <li> <p>新增相关库后，新表按新规则创建，特殊情况走特珠审批；</p> </li>     <li> <p>去SP去关联，让数据库减少计算，回归存储本质；</p> </li>     <li> <p>数据库拆分，改表改字段，采用模块整体迁移或应用重构；</p> </li>     <li> <p>一年后，再去看数据库，发现在没有特别立项和驱动的情况下，已接近一半的表在新库中。</p> </li>    </ol>    <p><strong>数据变迁</strong></p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/c48eb61ff9de0d42466ca8bf774618c9.jpg"></p>    <p>状态图是数据的变迁，是数据与行为的互动，数据的变化会引起行为的变化，行为的变化会产生数据的不同。上图是国内的订单状态变迁图，它的价值不仅属于数据库层，还在于SOA服务化和核心业务流程。</p>    <p><strong>2、服务改造</strong></p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/d190c099a243a47e114d5f0fb90eedec.png"></p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/a4a6586774c0ca0a76af8d64889ce87f.png"></p>    <p>服务是动词，是行为或活动的抽象，它的价值在于业务逻辑或行为的重用，具体实施过程如下：</p>    <ol>     <li> <p>服务列表和服务协议，在设计阶段使用Excel表格；</p> </li>     <li> <p>统一Request/Response规范；</p> </li>     <li> <p>服务实现，因没有直接可见的业务价值输出，最好以工单或项目来落地；</p> </li>     <li> <p>服务治理，早期没有工具时，使用WIKI做简单管理，后期使用专业的服务治理工具。</p> </li>    </ol>    <p><strong>领域模型</strong></p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/57734224b70487f6a5a106d0b9ae3a58.png"></p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/b1cac7d81f9744822561a41cbd826b5e.jpg"></p>    <p>没有领域图的架构设计都是耍流氓，我们画领域图的架构师是2位老员工，没有多少高大上，甚至于他们之前没有画过UML，但我们的状态图和领域模型都是出自他们之手。 <strong>其实画领域图的关键是懂事物本身，并知道它们的关系。</strong> 我们的领域图与业务模型中的5大业务流程一一对应，包括：预订流程，订单处理流程，产品供应流程，财务结算流程，账户管理流程。</p>    <p>微服务</p>    <p><img src="https://simg.open-open.com/show/632481fc3381c2de5fa2c4f8954037f5.jpg"> 我们的微服务JSOA V2.0是基于ServiceStack当时最新的版本号4.0.50实现的，它本身支持轻量级协议和Metadata，以及Swagger，是微服务的一种架构实现。另外，它还可以再扩展以API Gateway的方式实现Open API。</p>    <p>微服务MSA与我们之前的SOA、ESB有什么区别呢？</p>    <ul>     <li> <p>ESB有总线和聪明的管道管理能力；</p> </li>     <li> <p>SOA弱化了中间的管道和总线，强化了两端；</p> </li>     <li> <p>微服务MSA使用通用的轻量级协议和更加web化（RESTFUL）。</p> </li>    </ul>    <p><strong>3、应用架构改造</strong></p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d59b3dd08da113df3300afa140f56e29.png"></p>    <p>系统是什么？系统=元素+关系。应用架构是什么？应用架构=应用+架构。应用就是系统的最小单元，应用分级和应用编号则构成了应用关系即应用的架构，它有利于应用的管理、交互和追踪。应用分为产品线，子系统和应用3级，每一级编号为2位，如100206。应用要从用户的视角出发，先有用户，然后有应用功能，这样才是以用户为中心去构建系统。</p>    <p>4、组织架构微调</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/ee9590b2456d38c510e553731a91f594.jpg"></p>    <p>组织架构没有最佳实践，只有适合于自已当前的选择，以下是组织架构与技术架构对齐方面的思考：</p>    <ol>     <li> <p>艺术与工程相关分离：UED；</p> </li>     <li> <p>软件开发与硬件相分离：运维；</p> </li>     <li> <p>技术研发与业务研发相分离：架构部；</p> </li>     <li> <p>需求，实施，验收相分离：每业务线分产品组、开发组、测试组；</p> </li>     <li> <p>开发按业务职责相分离：预订组、产品组、订单组；</p> </li>     <li> <p>专业技术委员会制：测试、产品、开发、轮流主持，设委员长；</p> </li>    </ol>    <p><strong>总结 </strong></p>    <p>1、过程总结</p>    <ol>     <li> <p>第一步总体规划：手握地图，明确路线；</p> </li>     <li> <p>第二步数据库：建库拆库，去join去SP；</p> </li>     <li> <p>第三步中间件：按需构建，先增加常用；</p> </li>     <li> <p>第四步服务：技改=工单，有业务价值输出；</p> </li>     <li> <p>第五步应用：拆应用，建门户Portal，重构应用；</p> </li>     <li> <p>第六步组织架构微调：组架技术与组织架构对齐，技改之后调整；</p> </li>     <li> <p>第七步固化：框架化，自动化，管理过程工具化如DevOps。</p> </li>    </ol>    <p>2、经验感悟</p>    <ul>     <li> <p>从服务入手是错的，从数据库或中间件入手是正确的。服务属于高级阶段，方便行为的重用，是深层次优化，但太慢了；</p> </li>     <li> <p>从当前问题或故障入手，要先灭火，逆向分析dump工具很重要；</p> </li>     <li> <p>历史要尊重，早期不可做大的改动，不能过多地影响现有业务。建议只做加法，建新库和新中间件，这样就不会有太多阻力和负担；</p> </li>     <li> <p>一般不能全部重建，除非系统较小，系统规模大时只能拆分后分步重构；</p> </li>     <li> <p>技术并不是技改过程中最复杂的，人和事及关系才是麻烦的部分，历史问题的后面是人；</p> </li>     <li> <p>每次环境和问题都不一样，要有准备脱一层皮的心态。</p> </li>    </ul>    <p>3、通盘无妙招</p>    <p>技改是大折腾，于公司于个人而言都是，小改怡情，大改伤身，我们应该避免大的技术改造，但此现象又比较常见，特别是业务发展快的创业公司。所以真正高手下棋，应该是通盘无妙招，让正确的事情很容易发生，基于自然的演化来实现技术的演进。</p>    <p>怎样才能通盘无妙招，系统良性长久的发展？我们需要两个力量，一个是技术，一个是业务，如果只重视业务，而很容易在技术上积劳成疾，如果完全技术驱动，则又容易忘记业务目标。所以它们应该相伴相生，共同发展，在大的技术改造实施之后，在框架和流程相对固化后，小的技术重构项目应该长期存在，这样才能良性循环，让系统进入自然演进的状态。</p>    <p><em>5</em></p>    <p><strong>互动问答 </strong></p>    <p>问题：请问张老师如果再来一次技改你会怎么做？在你做过的技改过程中你觉得你最大的收获是什么？觉得做的不好的又是什么？</p>    <p>这个问题非常好，为了更好回答您的问题，我简单介绍一下本人的3次技改经历。我的第1次技改是重建，项目从10月份到第二年8月，历史10个月，可以说是技术成功项目失败。第2次技改是重构，只管技术，少管人和业务，整体效果好，可以归结为成功。第3次技改还是重构，既管技术又管人，且业务处于高速发展期，资源少，可以总结为技术与业务相伴相生，技术效果一般。</p>    <p>如果以后还有机会，自已就不再直接负责了，实在是太累，从内外各招几个架构师，并按上面的工作流程和方式，然后把握好技术与业务的关系和资源占用即可。回到具体问题：</p>    <ul>     <li> <p>如果再来一次，我会多参考第2次技改经验，即PPT分享的过程总结；</p> </li>     <li> <p>技改后的收获是脱胎换骨，技术和管理都有很大提升；</p> </li>     <li> <p>不好的地方：要更多的关注业务，以及平衡好业务与技术的关系。</p> </li>    </ul>    <p>问题：单块应用向微服务迁移时，平滑过渡有什么技巧？如何解决分布式事务一致性呢？还有关于微服务持续交付、测试、监控（语义监控）方面有落地工具吗？</p>    <ol>     <li> <p>平滑过渡的技术：直面当前系统的问题，不断有价值输出，然后参考上面的过程总结，先规划，然后中间件和数据库，最后是服务和应用；</p> </li>     <li> <p>分布式事务一致性：使用替代方案，如最终一致；</p> </li>     <li> <p>落地工具：MSA与SOA的治理没有本质差别，还是 DevOps / Trace / Metrics /，我们使用的是 ServiceStack / JMetrics / CenterLog / Jenkins /。</p> </li>    </ol>    <p>问题：如果旧有模块关联复杂，又影响现有系统性能，相关开发人员流失，不好梳理，改造有风险，重写老板不答应，该如何取舍呢?</p>    <ul>     <li> <p>旧有模块关联复杂，又影响现有系统性能：先灭火解决当前故障, 逆向分析dump工具；</p> </li>     <li> <p>相关开发人员流失：引进中件间，建立分享机制和学习型团队，讲技改总体规划，让每个人了解自已的价值和目标；</p> </li>     <li> <p>不好梳理，改造有风险：内招几个老员工成为应用架构师；</p> </li>     <li> <p>重写老板不答应：有业务价值输入，技改==工单或项目，借助业务项目来实现技改。</p> </li>    </ul>    <p>▽</p>    <p>延展阅读（点击标题）：</p>    <ul>     <li> <p><a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993440&idx=1&sn=2e69f5e6118ae86f1c248c8dd6c60a8e&scene=21#wechat_redirect" rel="nofollow,noindex">IT职业技能图谱（全套13张官方高清下载） </a></p> </li>     <li> <p><a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993580&idx=1&sn=bd268e3200cdfc3266c7ca87a9b196b2&scene=21#wechat_redirect" rel="nofollow,noindex">大促订单、PV双线破亿，解密京东商城交易系统的演进之路 </a></p> </li>     <li> <p><a href="http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993546&idx=1&sn=f137e7952b7fc7f5c13c2ffc02be0d9c&scene=21#wechat_redirect" rel="nofollow,noindex">Uber的底层存储从Postgres换成MySQL之后 </a></p> </li>    </ul>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993589&idx=1&sn=df5bdc30b58fd037fa9e83837a742c00&scene=0#wechat_redirect</p>    <p> </p>