为什么我们要搞这摊子事？
我得先跟大家掰扯掰扯，这套SOA，不是我们闲得蛋疼非要弄，而是被逼上梁山的。我们之前那套系统，大家都知道，就是个超级大泥球，学名叫“单体应用”，但我们内部都喊它“史莱姆”。你稍微碰它一下，它就能抖三抖，全线崩溃给你看。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.me
去年那阵子，为了搞个小小的功能改动，我们发布一次，前后测试加部署，至少要耗掉一个小时。但凡中间出了点错，那对不起，得重头再来。有一次，为了修复一个只有一行代码的Bug，硬是拖了四个小时才搞定，那天是周五晚上十点，我看着屏幕上那个转圈圈的进度条，当时心想：再不拆掉这个老东西，我就先疯了。
动手！从哪里开始切第一刀？
决定搞SOA之后，第一件事不是写代码，而是吵架。我拉着几个技术骨干，在会议室里贴满了白纸，我们得把这坨“史莱姆”里，到底藏了哪些业务模块，先给分清楚。刚开始真是乱套了，因为很多功能代码都是耦合在一起的，你中有我，我中有你。我记得光是讨论“库存和订单到底该不该算一个服务”这个问题，我们就足足撕扯了两天。
没办法，我拍了桌子，定了个最土的办法：谁最痛苦，谁先拆。 我们把目光投向了用户中心和支付模块，因为它们是独立性最高，但同时又是更新最频繁的。拆的时候，我们给自己立了规矩：
- 第一步：先跑起来。 老代码不动，先把新的API接口在新的服务里搭用最快的速度把核心业务流程跑通。
- 第二步：慢慢替换。 新接口准备好了，就逐步把老系统对这些模块的调用，全部导向新的服务。这招叫“绞杀者模式”，听着挺酷，但干起来就像是给一头大象做心脏搭桥手术，得小心翼翼地切断每一根血管。
数据迁移，简直是噩梦
服务可以拆，但最要命的是数据。我们一开始所有服务都共享同一个巨大的MySQL数据库。搞SOA，核心就是每个服务要有自己的数据。我当时想，直接把表搬过去不就行了？想得太简单了。
我们开启了数据同步的漫长旅程。为了保证老系统和新系统的数据一致性，我们引入了消息队列，要求所有对关键数据的修改，都必须通过消息通知给其他相关的服务。这个过程简直是煎熬。我们经常发现：
- 用户修改了密码，老服务里生效了，新服务里却没同步过来，用户登录不了，投诉电话直接炸了。
- 订单状态更新了，但因为消息队列的配置出了点小问题，几百条状态更新消息堆在队列里没发出去，我们半夜爬起来，手动把数据拉平。
那些日子，我感觉自己不是在搞架构，而是在做数据侦探，每天都在追查为什么这个字段的值是错的，那个表里怎么多了一行脏数据。我们甚至停掉了所有新功能开发，集中了所有人力，硬是花了一个月的时间，才把用户和支付相关的数据库独立开来，并保证了同步机制的稳定。那一个月，我的黑眼圈比熊猫都深。
今天的成果和新的烦恼
现在回过头来看，我们已经完成了三分之二的拆分工作。现在我们的核心服务——用户、订单、支付、库存——全部独立运行。最大的好处是，我现在部署一个新功能，只需要几分钟就能搞定，而且出问题也只是局部爆炸，不会像以前那样全线瘫痪。
但是，新的烦恼也随之而来。服务多了，虽然不耦合了，但监控和追踪却变得复杂起来。以前日志全在一个地方，现在散落在十几台机器上。哪个服务响应慢了？哪两个服务之间调用超时了？这些问题，如果工具跟不上，找起来比以前更费劲。
我现在正在研究怎么把分布式追踪和日志聚合搞上个月我们引入了一个开源的日志系统，但配置起来又是一套复杂的玩意儿。这趟SOA之旅，真是一波未平一波又起。但我不会停。看着我们系统越来越结实，越来越灵活，那份成就感是实打实的。我会继续把这个“SOA系列更新日志”写下去，记录我们一步一个脚印爬出来的经验，毕竟这些都是血泪史！
