微服务实施阶段模型

字数 4514阅读 4960评论 0赞 2

**本文作者：汪照辉  王作敬 中国银河证券股份有限公司 信息技术部IT研发中心**

------------

昨天同学群里一个美女同学单位要采用微服务，向大家咨询如何实施微服务，引起大家热烈的讨论。她们打算要做三期，但苦于缺乏必要的理论和实践，担心厂商忽悠她。目前的确是这个状况。微服务是什么，适合什么样的场景，前面我们也讨论过了。今天我们就微服务实施阶段模型进行简单的介绍，以及在没有技术能力把控微服务项目的时候，考虑引入微服务项目监理来协助企业微服务建设，作为采用微服务实施时的参考。

# 一、理解微服务

实施微服务首先要理解微服务，通常我们会拿SOA ESB和微服务比较，**SOA ESB重在集成，微服务意在重构**。采用微服务往往是需要重构单体应用的时候，为了后面单体系统转向服务化，实现系统融合，从数据层实现真正的数据清洗、去冗、一致性、标准化、完整性等数据治理能力，最终实现**为企业应用提供唯一数据来源**；在服务层方便的实现业务微服务，**构建企业服务中台**；基于服务中台可以**敏捷的对企业业务需求作出响应**，快速应对企业业务应用变化的需求。

# 二、微服务实施阶段模型

目前很多公司对微服务的理解不深，更不知道怎么实现，特别如果还要建立基础设施容器云平台或部署到容器云平台，更是一筹莫展。找厂商来实施微服务，又担心被厂商忽悠，怕最终做的不伦不类，真是两难啊。
对于微服务实施，基于我们SOA ESB的实施经验，我们定义为如下5个阶段，可行性评估级、采用级、应用级、企业级、生态级。这也可以作为评估微服务实施情况的模型。后面我们会从多个维度来介绍如何评估微服务实施阶段及微服务成熟度。

![图片1.png](/home/attachment/201805/21/923583_152688368784940.png)

随着微服务的持续应用和改进，逐步向更高阶段发展，收益也会越发明显的体现出来。微服务实施初期投入可能比单体应用要大，特别没有做数据清洗、通用数据模型的企业，需要的资金和人力投入会更大，这也可能是影响初期微服务实施成功和成效的原因。下面我们对每个阶段做简单的介绍。

# 三、可行性评估级

考虑采用微服务首先要做一些准备工作，比如行业内交流调研学习、邀请厂商交流、做PoC验证测试等，要确认采用微服务是可行的，能解决企业目前IT系统面临的问题，为企业带来的收益。所以我们定义初始微服务级别为可行性评估级。这是微服务交流学习验证的阶段，为采用微服务和实施微服务打下牢固基础。我们不能为了微服务而去采用微服务，因为微服务很热门，其他人用了，我们也要用。这样的想法是做不好的。任何技术都只是一种手段，你熟悉它、理解它，才能熟能生巧，为你所用，否则很可能成为累赘。所以要尽可能的去学习、去熟悉、去思考、去理解微服务。

当然最快的学习是交流，避免封闭起来，闭门造车。开放的心态多交流，和同行、和厂商不断的交流和探讨，对同一个问题可以倾听不同人的意见、想法，逐步能够融会贯通。在交流过程中对厂商能力的认识也会逐步地加深，也是为PoC测试和后期的项目预作准备。

深入的理解少不了动手去实践。无论说得多么天花乱坠，实际做的过程中才能看到、才能体会到差别。不去实践很多事可能是想不到的。微服务数据梳理、建模、编程、通信、治理、运营等涉及的基础设施、数据、架构、方法、组织人员、业务等都有不少难点，不要期望一蹴而就、一次成功，总是要在不断尝试、不断失败、不断改进的过程中走向成熟和完善。所以正式开始项目之前需要重视PoC测试。尽可能的多测试一些场景，尽可能多熟悉一些细节，测试的时间长短可以不用规定死，多测几遍也没关系，有疑问的地方问清楚，和不同厂商沟通，明白思维的差别。一个人的思维总是有局限性，所以要多听听不同人的想法。最终决定是否有必要采用微服务。

微服务当然有微服务的价值，但好的不一定是适合的。不仅仅考虑好的技术架构、还要考虑投入、现有人员的技术水平和能力、后期运维支持能力、服务改造的影响和风险等等，在决定采用微服务之前，这些都要进行评估的，在可以驾驭微服务架构的情况框下，才是可行的。

# 四、采用级

微服务方案具有可行性，那么就可以选择一个项目开始微服务建设。初始建议以非核心项目为起点，选择相对独立的一块业务来采用并实施微服务。万事开头难，微服务虽没有什么特别的技术，但细枝末节也纷繁复杂。采用微服务首先要考虑支撑微服务的基础设施平台。PoC测试中这些可能不是重点，但在实际的项目中，必须考虑标准化和规范化。微服务架构和容器云平台、DevOps方法论像是相辅相成的孪生兄弟，容器云支撑微服务的部署运营，DevOps协助微服务敏捷开发、持续集成和持续部署、持续反馈和持续改进流程。微服务的思想也可用于容器云平台的建设、DevOps流程的设计。容器云平台提供标准化的镜像输出、完善的基础设施环境、应用为中心的微服务管理、安全的访问控制机制、多层次的资源隔离、以及统一的容器云平台基础组件和中间件服务，比如日志、监控、告警等服务。日志、监控、告警等也是基础组件微服务。

在这个阶段很难具备微服务需要的这些基础设施平台和组件。要建设这些基础设施平台和组件也是不小的项目和工作量，所以初期可以采用临时的方案，松耦合架构，可以在后期逐步的完善和替换，比如日志，在建设的过程建立集中日志中心，公司所有业务的日志都可以采集到集中日志中心进行统一管理，数据集中，就可以方便的进行查询、统计、分析等。

微服务不一定非要部署到容器云，如果有微服务管理平台，微服务架构设计合理，可以方便的实现伸缩部署，部署在虚拟机上也许更合适。但这可能需要比使用容器云平台付出更多的努力来构建微服务管理平台。

# 五、应用级

这个阶段可能是一个最痛苦的阶段。就象人到中年，上有老、下有小，不得不承担顶天立地的压力。这个阶段可能多个微服务项目并行推进，微服务基础设施平台和基础组件也可能在建设和完善之中。问题可能总是层出不穷。随着微服务数量、节点数的增加，一些理论上正常的事情可能也变的不正常。新旧系统并行，一方面开发运营着微服务，另一方面不得不集成很多单体系统，数据可能需要双向流动，既要进行数据清洗、去冗，保持数据完整性和一致性，又要数据同步到不同的单体应用系统中以保证这些系统的运行。所以依然需要采用采用ESB Adapter集成的方式，先集成这些单体系统，然后逐步地进行功能分解，最后完成替换，也就是重构了此单体系统。

业务梳理，是实现微服务的基础。所有相同的业务功能梳理并提取出来，成为独立自治的微服务，为业务应用提供服务支持。比如客户维护操作、账户微服务操作、资金维护操作、订单维护操作等，都可以提取为独立的微服务。这些微服务又是客户交易平台的基础服务。还有单体系统中公共的功能提取出来形成公共微服务组件，就象我们说的日志、监控、认证、权限等都是公用的组件，提取出来作为基础公用微服务组件，这样微服务平台只需要实现一套日志微服务、监控微服务等组件，所有的业务应用共用这些基础的公共组件，不用每个应用都重复建设。这也是服务化实现服务共享的方式。所有这些微服务共同构成了企业服务中台能力，是实现企业业务需求变化快速相应的基础。

业务梳理说起来容易做起来难，千头万绪，纷繁杂乱。不同的部门不同的团队不同的人员各有自己的考虑，可能用到同样的数据，可能面对的是同一个客户，却是数据彼此隔离，格式、编码、存储方式等各不相同。如果没有公司级的强有力支持，业务梳理很难推进。我们也说过，做业务梳理的目的是理顺业务流程，实现数据治理，为企业提供唯一标准数据来源。这些数据没有冗余、没有错误、没有不一致、没有不完整。这样去实施微服务才更有价值。不过有困难解决困难，不能不去尝试。可以基于采用级微服务实施的经验，选择相对核心的系统来分解实现微服务，比如客户关系系统（CRM）。这一个系统可能涉及客户、账户、资金、订单、积分、消息等很多个微服务，基于这些微服务来构建新的客户服务应用、客户交易应用、客户积分管理应用、客户消息管理应用等。一个客户可能有多个账户，如果想实现一账通应用，就可以基于这些服务快速构建。其他单体系统的数据和功能逐步的合并到这些微服务，也就逐步建立起了企业的服务中台。

# 六、企业级

历经千辛万苦能走到这一步不容易。到达这一阶段企业的主要微服务都已构建，基础设施平台和基础组件都已逐渐成熟，建立起了企业自身的服务中台体系，企业不再有独立的单体系统，数据也都已经完成融合并得到良好治理，企业的数据通过唯一的数据源提供。这一阶段的主要任务是业务应用的快速响应和构建，以及微服务和基础组件服务的持续改进。

这一阶段压力会小很多，投入也很少了，主要是平台和微服务的运维以及新业务应用的开发运营。真正做到以业务为核心，快速的响应和部署。大部分业务应用通过服务编排都可以实现。企业的收益率明显的成倍提升。

# 七、生态级

一些企业也可能不需要到达此阶段。但大部分企业在万物互连的时代难免需要跟其他企业交互。比如我们跟京东合作，在我们的业务中引入他们的京东刚蹦，建立业务生态体系，相互依存。社会就是一个关系网络，企业也不可能独自生存，所以要考虑和其他企业的合作。IT系统和服务提供了便利的手段和工具，提供实时的联系和响应。这时企业的服务中台就会承担起主角，安全、认证、权限、连接、转换、过滤、分发、处理、响应中台能力等支撑起不同合作伙伴的业务互连需求。

这个阶段安全将会格外重要。不只是协议、数据、存储等安全，这也许会促进区块链等技术的发展。

# 八、引入微服务实施项目监理

微服务实施并不容易，在企业自身没有相应的技术实力能够把控微服务实施的话，可以考虑引入独立的第三方软件工程监理，保证软件交付质量，同时可以提供咨询、培训、架构设计、服务设计等方面的支持，具体实施可以外包或者由企业选择一家厂商来做。微服务项目监理对微服务实施工期、效果和质量负责，通常有一个人就够了，监控整个项目的方向、架构、计划、进度、质量等。微服务项目监理和实施最好不要由同一家厂商来做，由独立的第三方来承担。虽然可能多付出一些成本，但能保证整个项目的顺利进行，直到成功。就象为项目实施买了份保险，在出现意外的情况下由监理公司承担赔付责任。

目前虽然微服务很热，但国内实施微服务真正做的好的项目几乎没有，也可能是目前很多项目还未达到应用级和企业级等阶段的缘故。但总的来说微服务高端人才缺乏是一个不争的事实。大部分技术人员仅仅是编程，难以承担起微服务设计的角色。更因为微服务分解和设计需要熟悉业务，熟悉数据，不同的业务场景、数据存储、数据量、请求负载、技术选型等可能需要采用不同的设计。即便同一个微服务，在不同的阶段也可能需要不同的设计，持续的改进。所以采用微服务必须有专业的人才来支持。避免厂商技术人员能力，眼界、境界的限制，避免最终虽然叫微服务，却是不伦不类，依然有诸多瓶颈，难以发挥微服务的优势。

SOA 微服务 esb

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

微服务实施阶段模型

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料