服务切版那些事儿

服务切版是FMPOI自20150315上线后的第一个重量级架构调整。11月底形成方案，12月中旬开发完毕；...



服务切版是FM POI自去年上线后的第一个重量级架构调整。11月底形成方案，12月中旬开发完毕，经过2轮测试验证，1轮生产验证，今年2月底上线。

回头来看，这次切版一共做了3件事：服务拆分、自动部署、数据库统一调度管理。

就这点事情，就这么简单!（开发、测试、运维的板砖已经在空中划出了一条优美的弧线….）

但，整个过程很磨人：折磨人，也磨练人。（哥还有但是呢！）

1.服务拆分

我们的总架构师首先提出要服务拆分。

在他提出这个说法的时候，我们的服务架构是这样的：各种管理、数据处理、各种业务线，统统由一个FOS Server提供出来，可谓万千宠爱于一身。

隐患也随之而来，牵一发而动全身：改动一个地方，整个服务都得重启，全体业务线都受影响；

如果继续这么玩下去，越来越多的业务线、越来越多的用户访问，最后的结果必然是性能越来越慢，越来越难以扩展。到那个时候，积重难返，将付出更加高昂的成本。

So，服务拆分势在必行：将不同功能的服务分配到不同的server上面。



其实，像这类服务拆分或者说业务拆分，实际上是很多大型网站都经历过的一个过程。

往往在开始业务量小的时候，架构就是 ALL IN ONE，很多的东西都跑在一个server上面。当业务量增加时，单一的sever服务自然无法承受。

同时随着业务的增加，系统的维护必然也变得举步维艰：一个简单的改动，影响就是一大片。

未雨绸缪，改起！

于是，我们对FM服务进行归纳整理，将fos server 分为common server、admin server、data server、 biz server、statisticserver、hbaseData server。

这时，我们采用的策略是尽量降低代码底层的改动，而是将不同的服务按照业务规则划分，将代码分别迁移到不同的server上面。不同的server运行相同的代码，但是对外仅仅暴露各自负责的业务服务。



为了保证前端调用不受到影响，我们还采用了nginx作为几个server的反向代理服务，通过深度配置nginx，实现服务拆分对于前端调用透明。

小凯把各个server的服务分别写了一个配置文件，然后include到nginx.conf中，非常简洁清新。

于是，所有的这一切发生的都是那么自然安静，前端一点都不会觉察到。

2.自动部署

对于运维来说，之前要服侍一个server，现在多出来这么多server。可不是个轻松的事情了。

于是小毛老师又祭出了一件法宝fabric-自动部署。

自动部署不是简单的拷贝文件！！！不是，不是，不是。

我们和运维一起统一规划了各个服务器的路径：哪个路径放置程序包，哪个路径放配置文件；python程序放在哪？java程序放在哪？数据库脚本放在哪?……这些东西事无巨细，但是都影响到自动部署。

为实现自动部署，我们甚至重构了原来几乎全部脚本！为了一劳永逸，拼了。相应地，又带来了极大的测试量。

所以，看似简单的事情，在其背后往往是非常巨大的付出。

一周后，自动部署利剑出鞘！以前部署一次可能需要两个小时，现在，呵呵，分分钟搞定！

3.Datahub实现数据库统一调度管理

Datahub是大架构师对于本次服务切版提出的又一个重要的东东。

起因是原有的框架中，除了服务大人，还有一套mongodb大人，也是独享圣恩，各种库共存在一套mongodb server上。

一套mongo server意味着不同的业务资源在IO，内存方面的争用、意味着风险的集中、意味着我们不能根据业务的要求动态调整我们的分配策略。

那就拆吧，可是还不能只拆不管（只管拆的，那是具有中国设色的xx队），我们还得管。

Datahub就是这个负责拆，也负责管的大拿。



上图是目前datahub的一个实现描述。整体原理还是比较朴素。

各种类型的数据库首先需在datahub中注册，注册时定义了这些库的性质：是什么类型的数据库，具体库的物理连接情况、用于存放哪些类型的数据等。当我们想要创建一个库时，由datahub中的调度器依据一定的策略进行动态的调度；这样就将数据分配到了不同的的数据库服务器上面了，实现了数据的合理分配。有了datahub，整个系统架构中，数据库的水平扩展能力就具备了。

但是，大约一周后，兰陵散人实现了第一个版本的datahub。在把它集成到我们现有系统的时候，问题来了！原有系统中，因为使用一套mongodb server，所有连接信息都通过一个全局的变量来定义，散落在各个接口模块中。尽管小凯写了一个factory用以和datahub进行交互，以获取数据库的连接。但几乎所有和mongo操作的代码都要进行重构---------测试的同学已经按捺不住情感了，留下了辛酸的眼泪！

同一时刻，我们居然还做了mongodb升级，又给自己加了码。因为，据官方说法新版mongodb采用了新架构，性能方面提升可达10倍。我的天，不心动都不行。于是我们又掉到另一个坑里-------新版本的python驱动pymongo，有几个我们用到的API在升级时竟然没有被向下兼容：哎我去！

这个事实，完全颠覆我们惯常使用API的常识啊。没办法，为了提升性能，忍了、认了。兰陵散人花了一天时间整理了所有的API变更影响点，继续改。

2015年12月中旬，开发完工，约上测试、运维的同学开始介绍服务切版那些事：将服务的分组及相关的架构调整情况、datahub、mongo升级、自动部署说了个遍，还将需要回归的服务、脚本交了底。了解到这些变更影响，大家都笑了------略有苦涩：）

3.没有回头路

这么大的变更，设计评审过了几道堂，开发终于完成，那能不能测完？测全？会不会顺利发版？在什么时间发版？是压在所有人心上的石头。

最后，老大亮了底：3月开工必须上，否则再无合适的时间点。

于是，小伙伴们开始了艰苦卓绝的测试工作。

值得一提的是我们的测试组这时候放了大招：上了自动测试工具STAF。

使用这个工具，对受到影响的服务接口来进行测试验证，果然事半功倍。而且，众多优秀的测试人员参加到了这场战斗中。

他们写出的测试报告：从测试背景、目的、环境到方法、策略；从测试数据到实测数据和图表分析及结论；有思路、有方法，有数据、有分析。

看到这些亮瞎眼的报告，“靠谱”、“赞”这些词自然涌上心头-----保质、按时上线有望！

经过云服务器完成一轮测试后，我们已经积累了很多经验，包括环境的、程序的。

但这还不够，运维还没有上手，于是frog又提供三台验收服务器，由运维来搭建环境，进行各种演练。

就这样，三台验收服务器上面又进行一轮的测试，和运维同事进行各种评审，查漏补缺。

这下，基本上大家心中有数了，该想到的、该演练的，我们都有准备。于是我们笑了，不过这次已经轻松了很多。

春节一过，大家投入到正式环境搭建、环境验证、查找疏漏的工作中，终于，2月22日正式环境成功上线了。到目前系统已经运行近一个月，除中间修复了在并行处理方面的两个问题，整体来看相当稳健，完全达到预期。

纵观FM这个大故事，服务切版只是其中很小的一个剪影。可这个经历给我们很多启示：

1. 架构也是一个不断进化的过程：随着业务的扩展，团队技术能力的提升；我们需要采用更具有扩展性、性能更好、更稳定的系统架构。架构需要不断的被重构、演进。
2. 自动化：自动化在系统实施过程中，给我们带来工作效率的提升能力不言而喻。自动化的部署、自动化的测试、自动化的代码生成、自动化的日志分析....
3. 良好的设计是成功的一半：要重视设计，良好的设计是成功的一半。如果之前的数据操作层设计的很好，那么在接入datahub时我们就不用吃那么多苦。系统的设计决定了之后的扩展性，架构师、开发人员应该具有长远的眼光。

    关注 四维研发Family