百花齐放，百家争鸣的大形势下再谈微服务

字数 4687阅读 4276评论 0赞 3

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

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

微服务虽然火热，但到现在似乎都没有一个统一的认识。微服务到底有多“微”？微服务到底和过去的SOA、ESB有什么差别？微服务为什么要分库分表？微服务和数据是什么样的关系？ServiceMesh是什么鬼？Serverless又是什么东西？

现在有点各说各的，百花齐放，百家争鸣。说起微服务实施，见过大风大浪的国内某大云服务提供商来交流时都感觉为难，也可能是觉得我们这样技术落后的公司比较难实施，陷进来难以拔出去。唉，也没办法，历史问题，现实情况，所以我们也不断的努力学习，尝试提升我们的技术能力。言归正传吧，这里我们分享一下我们的一些思考，也算抛砖引玉，多一些交流多一些理解和提高。

# 一、微服务之“微”

我们天天说微服务、微服务，微服务会带来运维的复杂度，那微服务有多“微”呢？为什么会带来运维的复杂度？

Chris Richardson在《Introduction to Microservices》中，把一个实体做为一个微服务。比如乘客、司机、行程、支付等。实体有大有小，那微服务就不可能做到非常的微小，而且也没有必要。这里可能涉及到微服务的分拆问题。但是一个实体比如乘客，如何做分拆？性别？年龄？位置？……但是不管你怎么分拆，它都是“乘客”这个实体，所以似乎也不是微服务分拆的问题，分拆更多是微服务数据存储、性能考虑的问题，跟微服务之大小没有关系。

所以我们认为微服务并不“微”，“微服务”只不过是一个概念而已，并不代表大小。微服务可能比传统SOA架构的ESB服务更大，当然也更复杂。其实我们觉得，**微服务更多是相对于传统大而重的单体应用来说的**，传统单体应用各种功能高度聚合，各个模块高度耦合，所以这些传统单体应用运行维护是非常困难的事情，微服务架构才应运而生，来避免传统单体应用的大而重的缺点。

采用微服务架构，一个应用系统就必须由若干个微服务来通过松耦合的架构方式，采用分布式等技术来共同实现。如果仅有“乘客”微服务，无法构建一个交通服务运营服务系统。微服务实施采用的分布式技术、事务处理等必然带来应用系统的架构、实现、部署、运维等的难度。

# 二、微服务和ESB服务

微服务和ESB服务都是面向服务的架构方式，他们之间有没有什么必然的联系？我们觉得有联系是必然，至少都是服务化的架构设计方式，都是为了实现服务共享，提升开发效率和响应能力等。但微服务和ESB服务又是不一样的：

ESB服务主要是为了解决系统间的集成，实现服务共享、数据共享。它并不改造业务应用系统。所以ESB也有一个天然的缺陷，无论你怎么优化ESB，都可能无法满足业务的需求，因为系统始终有瓶颈。瓶颈就在于无法改造的业务系统或者数据库层。另外基于XML的数据交换也耗费大量的资源和时间，所以处于不上不下、夹在中间的ESB服务总是遭人诟病。

微服务比较聪明的一点是它要求业务应用系统的彻底改造。从数据层——数据库、数据存储以一种新的理念、思想和方式来实现。微服务实施困难也在于业务流程和业务数据的梳理很麻烦。这需要花费大量的时间和精力。而企业自身对业务和业务流程最熟悉，所以微服务的实施很大程度上企业自己做会更好，或者至少自己要作出梳理和整体的架构，低技术含量的编码和实现可以扔给合作伙伴。

以前的文章我们也提到，一个公司最重要的是**人才和数据**。对业务流程的梳理过程也是对业务数据的梳理过程。如果我们在做ESB、BPM的时候接触过主数据或主数据管理系统，对微服务的数据模型的定义和数据架构甚至数据治理都会有比较深入的体会。

# 三、主数据

主数据（Master Data）是企业内商定并共享的业务对象，它作为公共业务数据单一的来源在企业内多个系统、应用、进程等中使用。它是企业的高价值数据，比如：乘客、司机、行程、订单、支付等。

我们这里不是讨论什么是主数据，而是讨论使用主数据思想来实施微服务的可能性、可行性和便利性。
主数据其实就象我们一个人的骨架，首先在做业务梳理时，用主数据思想把主数据模型建立起来，我们并不是要建立一套主数据管理系统，而是采用主数据的思想，构建我们的微服务。所有技术一脉相承，万变不离其宗。所以我们在讨论微服务时，也不仅仅只是拘泥于微服务。

我们认为，实施微服务，最重要的是要**实现企业内数据的唯一来源，即单一数据源**。和传统单体应用数据散落于各个单体系统中不同，使用主数据思想实现数据的单一来源，从而实现数据的一致性、标准化、完整性、可靠性和准确性，形成一个权威的、可靠的、可持续的、精确的、安全的数据环境。这将给我们的数据分析、客户服务、业务研发等提供强力的数据支持。

前面我们也提到，采用微服务，需要对业务系统进行彻底改造。如果有主数据管理系统，其实我们觉得基于主数据管理系统上去实现微服务，也可以是一个暂时的完美方案。这样实现起来会很简单，但最终其实还是需要逐步的实现替换。不仅仅是减小运维的难度，更是可持续发展的需要，降低成本的考虑，层级越少，响应能力越强，业务迭代越快。国内企业基本上都没有主数据管理系统。甚至大部分人都没有关注过主数据的概念。那该怎么做？那就只能从业务梳理开始。比如乘客数据，在哪些业务流程中会用到乘客数据，每个业务流程中会用到哪些乘客数据，对乘客数据有哪些操作需求等等。这些是实现乘客这个微服务的基础。

# 四、数据分中心

数据分中心的定义是考虑采用微服务架构之后，基于数据管理治理的需求而构建。传统方式我们有一个数据中心，企业几乎所有的数据都同步到数据中心，然后由数据中心提供数据服务。所以数据中心往往会成为一个困难户。既然微服务都有自己的数据存储和数据库，那就可以考虑微服务建立自己的数据分中心，消除数据不一致、不完整等情况，提供单一数据来源，业务应用需要的数据都通过微服务来提供，禁止直接操作数据库或数据存储文件。

数据管理依然可以采用数据中心统一管理的方式，只不过每个数据分中心存储的是微服务单一的数据，比如客户数据分中心只有客户数据，账户数据分中心只有账户数据，产品数据分中心只有产品数据。

我们也提到过微服务对数据治理要求较高，其实如果企业能实现唯一数据源能力，数据质量在持续改进中就会逐步提高，直到完善。有很多的数据治理理论方法，不过我们觉得最好的方式是基于业务需要，来逐步的完善数据，提高数据质量。

# 五、服务粒度

基于前面的讨论，去实现微服务，应该说可以入门了。那服务的粒度如何确定?这也是一个很重要的问题。比如说客户，可以划分为机构客户和个人客户。那是“客户”作为一个微服务还是拆分为“机构客户”微服务和“个人客户”微服务？系统中还有一种划分方式是客户和潜在客户，是不是也提供客户微服务和潜在客户微服务？有时还真不太好分。分析客户实体的属性和业务使用场景，可能会发现机构客户和个人客户属性差别挺大，那就有必要把客户这个实体进行分拆，实现两个业务微服务：机构客户微服务和个人客户微服务。服务的粒度往往需要根据实际的业务、实体模型和数据量的大小来确定。但是有时基于这些原则划分之后，一个实体可能仍然有百万千万级甚至更多的数据量，比如交易数据，持续增长。这时候微服务的实现就需要考虑分库分表，比如按地域、按ID号等属性平均分布于不同的数据库或不同的数据表。这也是存储、性能等方面的需求所决定的。

这里可能涉及服务的配置问题，关于服务配置的设计方案，我们在《容器云服务配置中心设计》有详细的讨论，有兴趣请参阅那篇文章获取详细的信息。

# 六、服务实例

一个微服务可能分库分表，在服务部署时就可以根据库和表的数量来部署相应数量的微服务实例，当请求到来时，通过路由的方式把请求路由到合适的微服务实例。这有点类似于Kafka Topic Partition的方式。殊途同归吧，原理都是一样。即便是不分库分表，一个微服务也可能部署多个服务实例。服务和服务实例是两个概念，我们在谈微服务的时候一定要弄清楚，一个是设计时概念，一个是运行时概念。运行时有很多服务实例，这么多服务实例的部署、维护，还有请求的路由，服务实例不同的配置管理等等，这就带来了运维的难度。所以很多工作需要借助于自动化的工具来实现管理，比如容器编排调度，自动资源分配等等。

基于一些性能考虑，可能还需要采用缓存、缓存数据库，数据网格等技术，来满足不同的业务需求。

# 七、微服务是一个自治的单体应用

微服务可以独立部署，有清晰的边界，每个服务有自己独立的数据库，甚至可以有多个库，基于相应的规则来管理这些库。所以我们觉得微服务就是一个相对独立的、自治的单体应用。就好比社会关系中的一个人，都是独立的个体，这些独立的个体又构成了一个相互联系的社会。但是微服务呢，并不需要五脏俱全，它只关注业务逻辑，提供统一的接口，并不关心用什么语言实现，不需要提供额外的能力，只对自身实体提供操作的能力。我们觉得拿人类社会和微服务系统类比，还是挺形象的，有助于我们更好的理解微服务。人类的个体可以独立存在，微服务自身也是；微服务之间的通信是基于标准的定义好的接口，人与人之间的沟通是基于相同的人类语言，不同人类语言之间的沟通就需要翻译，就好比微服务之间不同的接口通信需要进行转换一样。每个人有提供不同资源的能力，每个微服务也是为其他服务或应用提供资源——数据。如果都用相同的语言沟通，比如都用英文，或者普通话，不在于你来自哪里，无论亚洲、非洲、欧洲或美洲。相同的接口定义，也不在乎它部署在什么地方。

# 八、业务应用

有了微服务，这路才走了一半。需要用微服务来构建业务应用。微服务是独立的一个个人，由一个个独立的人来组成家庭、社会团体、公司、政府、国家等等，这些就是我们的业务应用。每个服务提供多种操作能力，在不同的业务应用中可能会选择不同的服务操作，就象一个人在不同的社会关系中承担不同的职责。在家庭，你可能是父亲、丈夫、儿子；在公司，你可能是高管、中层或职员等等。

# 九、ServiceMesh

ServiceMesh又被称为服务网格，很多人称其为新一代微服务。我们觉得吧有点扯。把它作为新一代微服务实现方式可能更贴切些。更多的还是为了简化微服务实现和治理的难度。我们更推荐使用API Management和API Gateway来实现微服务API管理和服务治理等能力。

# 十、Serverless

我们突然发现Serverless已经火的不行不行的了。赶快查资料学习，我们发现Serverless思想和我们集成事件处理和复杂事件处理的想法是一致的。一个函数，或者一段逻辑，可以看做是一条规则，根据业务需要定义规则，规则的处理扔给规则引擎，对于用户来说并不需要关心规则引擎在哪里，甚至不需要关心是不是有规则引擎，只需要定义业务规则就好，规则引擎可以由云计算平台提供。事件在微服务之间流转，匹配到规则则触发，处理完毕返回结果。

简单的我们可以提供一个微服务，实现事件规则的发送部署，然后让规则去执行，返回执行结果，执行一次或者永久，在于规则的定义。可以不需要学习Serverless开发框架什么的了。你可能说你们没有复杂事件处理系统，那就部署一个吧，会有用的。

# 参考文献

1.Chris Richardson 	Introduction to Microservices

Serviceless ServiceMesh 微服务

著作权归作者所有

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

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

百花齐放，百家争鸣的大形势下再谈微服务

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料