【实战】微服务实施整体方略

许多企业都有业务系统庞杂，想拆解微服务，进而可以降低运营成本，提高开发效率和速度，同时达到节点快速迁移的目的。
恰巧小编最近刚做了一个航空公司的业务系统改造项目，需求是将现有的核心业务拆解微服务，将所有服务模块假设在云端，自由扩展以应对未来各种复杂的开发环境。
在第一阶段的调研中，小编发现该公司的的核心系统都是传统单体式应用（Monolith），应用间协同通过API接口调用。系统存在严重的重复开发的问题（比如中间件，数据库等）。

在这样一个系统中，平台的VMWARE，中间件，底层开发平台Java，应用开发Python和网页开发JavaScript被集中在了一起，每个部件的更新升级都牵连了所有其他部件的关联测试，效率极低。
迁移微服务的第一步就是将一个庞杂的系统拆解为耦合程度不同的各个功能模块，从流程上拆分，一个航空订票系统可以拆解为订票、更新用户信息、创建用户、时刻表查询、计费、选座及更新票仓六大功能模块，模块的高度代表了被调用的频率。

拆解后的服务都是相互独立的，服务间通过REST或SOAP调用（下期我们来介绍SOAP），拆解完成之后，应用层和中间件就分离开来了。

此时我们发现，系统的底层还是运行在一个虚拟机的操作系统之上，严格意义上说应用模块间并没有完全解耦。并且中间件要给适用各种开发平台，就需要定义不同的接口标准。
微服务化之后，应用的复杂度从内部转向了外部。各组件的开发和调用变得简单了，但对外部的接口就无法统一了，这包括了业务接口以及运维接口。 微服务化后，对外API需要重新整合，有些API甚至需要关闭对外发布。

为了满足上面提到的系统资源动态分配，在考虑操作系统的时候，也要跳出固有的VM框架，建议将其部署在更进一层的PaaS服务（至少操作系统是分布式的）上，这里的PaaS可以是私有云也可以是私有云。同时应对不同开发平台的中间件服务，需要定义不同的API以优化上层调用的便利性。