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

摘要

微服务实施的不仅仅是微服务开发微服务技术的问题，更涉及到数据治理、人才培养、架构设计、系统集成等多个方面，微服务实施之道从人才培养、数据治理、事件驱动架构、微服务治理等几个关键方面来讨论如何来实施微服务，从思想理念上真正认识到微服务成功实施的关键（道）。

为了保持竞争力，我们必须适时改革。而IT作为业务基础，就是要不断的显著改进开发和运维的效率，提升响应能力。所以也在不断的提出很多新的概念。

目前火热的容器、人工智能、微服务等技术也逐步在各公司落地，但实施结果并不令人满意。微服务是好，但也不是放之四海而皆准的道理。说到底，微服务只是实现业务需求的一种方式、一种手段。ESB曾经作为系统集成的实现方式，解决了单体系统间数据和服务的共享；而微服务要求从数据层进行优化和分拆，不但要求极高的服务治理能力，更要求极高的数据治理能力。所以在实施微服务之前，必须深入理解数据治理和服务治理以及事件处理技术，掌握这些能力，然后才能成功的实施微服务。有句话叫：熟能生巧！如果仅仅听别人说几个概念，听别人吹嘘微服务多好多好，能解决所有问题就去实施微服务，那结果肯定是一团糟。曾经的ESB不好吗？不是ESB不好，是ESB实施的不好。不懂不能跟风，潜心理解之后，才能事半功倍。否则，神马都是浮云。

一个公司什么最重要？人才和数据！人具有智能，具有主观能动性，特别是IT这种高智能行业，没有人才也就谈不上领先的IT技术。数据更是一个公司的核心资产，没有数据，就谈不上数据服务，谈不上大数据分析，更谈不上人工智能。就像巧妇和大米关系，有巧妇（人才）有米（数据）才能做出可口的饭菜（满足需求的优秀的业务系统）。

微服务与人才培养

工欲善其事，必先利其器！不只是微服务，任何一门技术，想要做好，就必须有深入的理解，不说融会贯通，至少能比猫画虎。在实施微服务之前，学习微服务技术是必须的。

最近也参与了一些讲座和宣讲会，不少这方面的专家也分享了很多经验和心得，有这种技巧那种技巧，这种方法那种方法，还有各种各样的原则。深入思考了一下，这些更多是厂商自我能力的推销，并没有真正从客户的角度考虑如何实施好微服务。人才培养也不是一天两天的事，厂商也不可能长期帮你培养人才。他们提的这些技巧方法原则是让你相信他们有能力帮你做好这些事，但厂商有没有能力有没有时间理解你的业务你的数据？你有没有能力接手？这才是关系到微服务实施的成败。所以要实施微服务，第一步要做好人才培训的规划并培养微服务人才。

所谓见多识广，可以多安排一些和厂商的交流，多参与一些专题讲座和讨论会，多加入一些微信技术群跟踪技术趋势，多思考，可以快速的理解和提高。

微服务与数据治理

我们说数据是企业的核心资产。实施微服务，数据是分布式管理的。数据是分布到不同的数据库，可能不同的地方不同的数据中心。和我们传统的单体应用、ESB集成，数据散落于各个数据库是不一样的。这就对我们提出了更高的分布式数据的管理和治理能力。

传统单体应用中，客户数据可能分散在不同的应用系统中，比如CRM、产品系统等等，各个系统中可能客户数据不一致、格式不一样，为了实现各个单体应用之间的数据共享、服务共享，很多企业逐步实施了ESB，以实现系统间的集成；为了实现企业的数据治理，也有不少企业实施了主数据管理，对企业数据进行分析、采集、清洗、转换、充实等操作，为公司业务提供唯一的数据来源，解决数据不一致、数据冗余、管理混乱等问题。

有了这些经验，我们在实施微服务时，数据层数据的分拆、分库分表其实就是一个数据治理结果的应用。ESB服务的治理思想理念同样可以应用于微服务的治理。所以有ESB、主数据管理的经验，在进行微服务实施时就相对容易很多。数据治理的越好，越容易快速的实现微服务并获得实施微服务的收益。

我们不是说非要先去做ESB、主数据管理，而是要理解其思想和理念，理论指导实践，实践需要结合理论，才能不断的完善进步。所有技术万变不离其宗，各行各业理论也是相通的。

实施微服务我们更多考虑的是分库分表，如何分拆数据，这就是我们所说的分布式数据管理。数据治理的好，数据才好管理。另外一个微服务操作可能涉及到结构化数据和非结构化数据，SQL数据库和NoSQL数据库，开发业务事务来操作多个微服务拥有的实体将是一个挑战。

微服务与事件处理

目前也有提出事件驱动的微服务实现。使用事件驱动来保证事务最终一致性。使用事件处理来实现跨多个微服务的业务事务最终一致性。ACID事务被多步的、事件驱动的最终一致性流程替换。每一步， 服务更新其数据并发布一个事件来触发下一步。

另外也可以用事件来维护一个或多个物化视图。每个视图都是针对特定的查询集进行优化。维护视图的服务是通过订阅系统更新时发布的事件来完成的。

开发事件驱动的微服务，我们需要理解事件处理甚至是复杂事件处理概念和实现。每步发布一个事件一些场景性能显然跟不上，既然使用事件驱动，那么我们是不是可以一步发布多个事件来并行处理没有相互依赖的步骤？理解复杂事件处理，理解事件规则定义，那么微服务的实现将会有更多选择。同样，微服务也可以和复杂事件处理系统集成，使用复杂事件处理系统规则引擎来实现复杂的业务规则处理，然后返回处理结果。比如大数据、AI的一些统计分析算法，机器学习深度学习算法。

微服务治理

实施实现了微服务，就需要管理治理好这些微服务。不能说只生孩子不养孩子，养孩子比生孩子更辛苦，所以说管理治理好微服务比开发微服务更难。

服务治理和服务管理涉及的内容比较多，包括服务注册发现、认证、授权、准入、资源隔离、限流、熔断、路由、服务映射配置转换、过滤/反爬、优先级、服务降级、负载均衡、健康检查等等；还可能需要统一认证、单点登录、弹性伸缩、灰度发布、编排部署、版本控制、预警告警、日志、监控、通知等等。不只是微服务，ESB服务同样面临着这样的需求和问题，微服务更甚而已。所以做好微服务治理和管理是我们实施微服务过程中至关重要的内容。如果有ESB经验可以更好的使我们理解微服务，使用微服务，管理和治理微服务。

微服务治理首先是服务的注册和发现机制，目前也有很多工具和实现方法。容器云平台一般也都有自己的服务注册发现机制，比较成熟的SpringCloud框架是目前理想的工具，最近逐渐热起来的ServiceMesh服务网格以及Kubernetes平台上的服务开发和治理框架Istio等，也都有自己的独特的思想和设计。

实施微服务，服务配置和服务运行时配置的实时推送和调整是不可避免的问题。比如Log Level在运行时的变更，在异常或某些情况下想要获取详细的Trace或Debug信息，有时很难要求重新启动服务来实现，那么在运行时实时改变参数配置，来改变服务的行为和输出，将能更灵活的满足需求。再比如通过服务路由参数的调整来路由服务请求到新的服务版本，从而实现分流；调整服务优先级参数来实现服务的降级等需求。这些都是在不需要修改代码也不需要重启服务的情况下实现的。

服务治理主要在API Gateway部分来实现，TIBCO公司多年前推出的TIBCO API Exchange就有相似的思想。它提供API Exchange Manager，一个中心化的控制面板，通过配置，实现服务的映射转换，与开发语言无关，与协议接口无关，与部署位置无关，它在API Exchange Gateway定义一个虚拟接口对外提供统一的服务。同时实现服务的映射转换、服务的认证授权、服务的限流、服务的熔断、服务的路由等功能。不用修改代码，支持不同协议，不同开发语言开发的接口服务。API Gateway面临的一个问题是需要支持分布式部署，否则会成为整个系统的瓶颈。Service Mesh, Istio也是重在简化服务的开发，更多的提供服务治理的能力。

这里我们提出一个微服务生态系统，也就是支持微服务运营的服务的注册发现机制、支持配置实施更新的服务的配置机制、服务的日志、服务的监控告警通知机制、服务的API Gateway以及服务的Open API文档管理，还包括服务的认证授权、安全权限机制等，这是微服务运营的基础组件设施。理解了这些，再去选择合适的工具和framework，就有的放矢了。

总结

总的来说，微服务实施不难也不容易。但想要成功实施微服务，至少需要有一个能把控全局的人员来指导、协调整个团队的工作。从整体上考虑，需要安排人员的培训学习、技术难点的攻关推演、微服务架构的设计、数据的来源、接口的定义、系统的集成、基础组件的研发等工作。千头万绪不离其宗，所谓会者不难，难者不会，就是这个道理。