微服务及其在银行业中的发展

1. 什么是微服务？

       微服务这个概念最早在2011年5月威尼斯的一个软件架构会议上讨论并提出，用于描述一些作为通用架构风格的设计原则。2012年3月在波兰克拉科夫举行的第三十三届 Degree Conference大会上，Thoughtworks首席咨询师James Lewis做了题为《Microservices - Java, the Unix Way》的演讲，这次演讲里James讨论了微服务的一些原则和特征。

       而微服务架构则是由Fred George在2012年的一次技术大会上所提出，在大会的演讲中他讲解了如何分拆服务以及如何利用MQ来进行服务间的解耦，这就是最早的微服务架构雏形。而后由Martin Fowler发扬光大并且在2014年发表了一篇著名的微服务文章《Microservices -a definition of this new architectural term》，这篇文章深入全面的讲解了什么是微服务架构。随后，微服务架构逐渐成为一种非常流行的架构模式，一大批的技术框架和文章涌现出来，越来越多的公司借鉴和使用微服务架构相关的技术。

关于微服务与微服务架构的学术定义，引用Martin Fowler的一段描述如下：

      “微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通。每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构造。”

从中可以发现关于微服务一些关键特征，包括：

• 小粒度，更灵活，可独立部署；
• 可独立运行，进程隔离；
• 轻量通讯，基于Rest或RPC风格的交互方式；
• 高内聚，松耦合，专注于一件事；

这就要求每个微服务实例能够控制自己业务领域的数据资源，可以实现数据分离，并且自身的运行状态与其他微服务实例之间的运行状态无关，并且微服务实例之间可以进行通讯完成信息资源交换。

       另外，需要注意的是，相比于传统SOA理念中的“服务”而言，“微服务”是一个业务领域通过抽象形成的总体聚合，不单单是一个对外暴露的一个功能点、接口或方法。微服务不是对于传统SOA服务的细化，而是基于业务领域、领域事件、业务实体进行的系统解构，“微”是对于传统系统架构而言的，不是对于服务功能本身而言的，不能认为更细粒度的功能划分对于系统总体建设是永远有利的，颗粒度适中才是应该被追求的。

所以，综合学术定义与过往的架构设计知识，对微服务作出如下通俗易懂的解释：

1. 微服务（Microservices），是一个业务领域的聚合，包含了在运营该业务领域过程中全部业务数据、业务流程和处理逻辑，并以高内聚、松耦合作为设计目标，专注于完成处理一项业务领域的事务。
2. 而实现这个的业务领域聚合的应用，称为微服务实例。微服务实例之间可以实现独立开发、独立部署、独立运行，独立监控，可以横向增容，并且彼此间采用标准的通讯方式进行信息传递，实现跨领域的上下文交换。
3. 能够为上述微服务实例提供运行环境，铺垫基础设施，填充公共技术能力，实现微服务实例上述能力的集成应用，我们称为微服务平台。
4. 最后，通过微服务自身与微服务之间的配合衔接，完成业务工作、满足用户需求、实现业务价值的架构体系称为微服务架构。

再通俗一点来说，微服务类似于古代著名的发明，活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。

2.微服务的优势 

    微服务之所以能盛行，必然是有它独特优势的，下面我们来分析微服务有哪些方面的优势。

    （1）技术异构性 

    在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。如要开发一个社交平台，此时，我们可能使用文档型数据库来存储帖子的内容，使用图数据来存储朋友圈的这些关系等，这样可以把每一块的性能都充分发挥出来。同时，在应用新技术时，微服务架构也提供了更好的试验场。因为对于单块的系统而言，采用一个新的语言、数据库或者框架都会对整个系统产生巨大的影响，这样导致我们想尝试新技术时，望而却步。但微服务不同，我们完全可以只在一个微服务中采用新技术， 待技术使用熟练之后，再推广到其他服务。

    （2）弹性 

     弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中，一个部分出现问题，可能导致整体系统的问题。而微服务架构中，每个服务可以内置可用性的解决方案与功能降级方案，所以比单块系统强。

    （3）扩展 

     单块系统中，我们要做扩展，往往是整体进行扩展。而在微服务架构中，可以针对单个服务进行扩展。

    （4）简化部署 

    在大型单块系统中，即使修改一行代码，也需要重新部署整个应用系统。这种部署的影响很大、风险很高，因此不敢轻易地重新部署。而微服务架构中，每个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。

    （5）与团队结构相匹配 

    我们都知道，团队越大越难管理，同时团队越大也代表系统规模越大代码库越大，这样容易引起一系列的问题。且当团队是分布式的时候，问题更严重。微服务架构就能很好地解决这个问题，微服务架构可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。服务的所有权也可以在团队之间迁移，从而避免异地团队的出现。

    （6）可组合性 

    在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

    （7）对可替代性的优化 

    在单块系统中如果删除系统中的上百行代码，也许不知道会发生什么，引起什么样的问题，因为单块系统中关联性很强。但在微服务架构中，我们可以在需要时轻易地重写服务，或者删除不再使用的服务。

3. 微服务面临的挑战

    软件开发业内有一句名言“软件开发没有银弹”，虽然前面介绍了微服务很多方面的优势，但微服务并不能解决所有问题。下面我们来分析在使用微服务架构时可能面临的一些挑战。

    （1）分布式系统的复杂度

    使用微服务实现分布式系统的复杂度要比单块系统高。这表现在多个方面，如：性能方面微服务是拆分成多个服务进行部署，服务间的通信都是通过网络，此时的性能会受影响。同时可靠性也会受影响。数据一致性也需要严格控制，其成本也比单块系统高。

    （2）运维成本

    相比传统的单块架构应用，微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。这就意味着，原来适用于单块架构的集中式的部署、配置、监控或者日志收集等方式，在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、监控、日志收集等，因此成本呈指数级增长。

    （3）部署自动化

    传统单块系统部署往往是以月、周为单位，部署频度很低，在这种情况下，手动部署是可以满足需求的。而对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。这样部署的成本是比较高的，如亚马逊，每天都要执行数十次、甚至上百次的部署，此时仍用人工部署是行不通的，要使用自动化部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。

    （4）DevOps 与组织结构

    传统单块架构中，团队通常是按技能划分，如开发部、测试部、运维部，并通过项目的方式协作，完成系统交付。而在微服务架构的实施过程中，除了如上所述的交付、运维上存在的挑战，在组织或者团队层面，如何传递 DevOps 文化的价值，让团队理解 DevOps 文化的价值，并构建全功能团队，也是一个不小的挑战。

    微服务不仅表现出一种架构模型，同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

    （5）服务间依赖测试

    由于微服务架构是把系统拆分为若干个可独立部署的服务，所以需要进行服务间的依赖测试。在服务数量较多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作，成为微服务实施过程中必须面临的巨大挑战。

    （6）服务间依赖管理

    传统的单块系统，功能实现比较集中，大部分功能都运行在同一个应用中，同其他系统依赖较少。而微服务架构则不同，在将系统功能拆分成相互协作的独立服务之后，随着微服务个数的增多，如何清晰有效地展示服务之间的依赖关系，成为了一个挑战。

4.微服务与SOA

    微服务可以讲是 SOA 的一种，但仔细分析与推敲，我们又能发现他们的一些差异。这种差异表现在多个方面，具体如下表所示：

    这些差异自然影响到其实现，在实现方面的主要差异如下表所示：

5.微服务在银行业中的发展

     从银行IT架构整体发展趋势来看，伴随着银行业务和技术的发展，其整体架构一直在演变发展，现阶段已经进入到微服务架构建设阶段。微服务的技术也是逐步发展完善的过程，已经完成从微服务1.0到微服务2.0的进阶，从最初的强调分布式、去中心化、服务化、模块化，进阶到现在注重云化支持和异构化微服务支持的服务网格。发展历程可以从下图看到：

为此，银行未来需要一个面向企业级的微服务平台产品，可以把整个银行业务系统搬到云上面，实现银行整体微服务化的建设目标。未来整个微服务系统建设，会朝着能够解决全行系统的横向扩展的趋势去发展，以应对海量用户和海量交易处理的系统要求。

6.一个典型的银行微服务架构什么样的？

     银行架构中传统应用系统在短期内肯定无法完成替换和改造这是一个必然事实，因为一方面，要完成传统应用系统内部业务领域的梳理需要一定的时间，另外，传统系统的迁移不仅要花费一定的成本，也蕴含这巨大的风险。所以，传统应用系统和微服务架构应用会在一段时间内并存的情况不仅会在一家银行IT架构内部存在，也会在整个行业的架构设计中长期存在。基于这种情况就需要一套能够维持双模体系的架构，并且为两套模式架构提供完善的信息交换机制，进而实现稳态架构与敏态架构相结合，传统业务区与微服务区双模建设。其中，ESB负责作为衔接传统应用区域微服务应用区的信息传递桥梁，完成传统服务区与微服务区的信息传递。传统架构与微服务架构相结合的框架图如下：

7.微服务架构与分布式架构的关系是怎样的？

     金融行业IT领域发展至今，已经肯定不会存在，依赖一个单体系统实现全部业务价值与能力并且依赖单体系统可以持续支撑企业的成长了。所以，应用系统设计趋向专业化是一种必然发展方向，但是在早期的银行系统架构中习惯树立一个又一个独立系统，彼此间多为复杂、网状、难于维护管理的紧耦合架构，不仅独立系统内部设计复杂，独立系统间彼此交互的接口也十分混乱，上下游系统间的接口没有统一管理，充斥着大量的“私约”，几乎不存在交易链路的概念，系统维护改造难度巨大。所以，在这样的背景下，行业内部发起了以面向服务架构（Service Oriented Architecture，SOA）为设计模式的革新，其倡导通过建立规范的服务契约约束接口设计，整合全行级技术资产，形成层次丰富的金融服务库，降低各系统间的耦合度，提高信息系统总体架构的灵活性。基于此，实现简单系统开发维护的复杂度，实现高效敏捷的系统建设。总体上行业的SOA架构模式可以分为以下两个发展阶段。

（1）基于集中式企业服务总线（ESB）技术实现阶段

（2）基于分布式企业服务总线（ESC）的技术实现阶段。

     一般情况下，企业服务总线（ESB）更多的被理解为一种基础的SOA技术平台，是一种为企业构建满足业务发展要求、IT架构发展需求的企业应用系统整合技术。商业银行通过企业服务总线系统建设，整合了商业银行的系统资源，为实现多层次、条线化、松耦合的系统架构奠定基础。但是，无法回避的是，集中式的ESB成为了全行架构的神经中枢，成为了那个最重要的核心节点，对网络与计算资源的依赖十分严重。最重要的是，ESB成为了生产安全的核心系统，如果ESB发生不可补救的问题对于整个业务运用，即使是不相关业务线，也会产生巨大影响。

     于是，基于分布式企业服务总线（ESC）的出现则有效地解决了这个问题，即将物理上的总线分散开，通过部署Agent或其他的代理通讯模式，将总线结构虚拟化。即逻辑上是存在的总线体系，但是去中心化，将压力分散于各节点，使得其不仅保证了运行的安全稳定，还提升了通讯效率。ESC的价值就体现在既维持了SOA体系的完整性，接口的规范性，服务资产的层次性，也突出了分布式系统架构的独特优势。

      ESB或ESC技术平台下的SOA架构推动了各个独立系统间的协同意识，使银行业内对与IT技术资产的认识提升了一个新的高度，对于提高重用性和降低复杂度形成了共识。但是，无论是基于哪种技术平台的SOA都无法解决另一个问题，那就是独立系统内部本身的复杂度没有被降低，系统边界的壁垒依然没有被打破。

      举个例子，例如几乎每个银行都拥有一个核心业务系统，包含了完成银行主体业务的大部分功能，尽管曾经有过关于“胖核心”“瘦核心”的纷争，但是，依然不可否认是，在实际的IT建设实践中核心系统内部的复杂程度远远超过了想象。有的银行业务核心包含了十几个甚至几十个模块，横跨了几乎全行全部的业务线，再加上管理的缺失，长期以来系统内部的逻辑依赖已经没人能够梳理清楚，甚至有些接口和单元的功能也没人能够说清，不得不重新开发。由于核心系统的关键位置，使得维护和更新变得危若累卵，不断形成技术债务，形成恶性循环。微服务架构至此应运而生，即从打破系统壁垒的层面，降低复杂性、聚合业务资源，从另一个角度解决了这个问题。

      所以，可以看出经过不断地演变和发展，微服务架构脱胎与分布式架构，传统意义上的分布式架构可以说是微服务架构的理论基础，而现代意义上的分布式架构其实算是微服务架构的基础技术支撑。

8.微服务与服务的区别是什么？

     从前面微服务架构的演进由来，我们可以看到，SOA架构是微服务架构的发展基础和理论源头，企业也很难跳过SOA的阶段进入微服务的阶段。如果没有SOA对于推动达成统一共识的过程，微服务的落地也十分困难。一般行业内部认为微服务架构是SOA的子集，但是微服务的可独立部署、可独立运行的特性让他具备了常规SOA服务所不具备的优势。但是，这里一定要说明的是：微，不意味着就是要对已有的服务下手，不一定意味着要把已经有的服务切分成更细的粒度，因为微服务其实是一个全新的管理粒度，其实是对复杂系统的解构，尤其是过分的小粒度服务反而会带来链路复杂性使整个业务难以理解。所以对于微服务的设计需要一种全新的方式。

     从概念上来说，SOA服务在服务层次上更加关注基于功能的分层，期待实现服务的请求方和服务的提供方隔离，注重的是消费方只需要关注功能本身，而不需要关注如何实现，并且强调服务是面向全体的发布，通过服务授权完成调用申请。另外一个需要关注的是，在建模形式上，SOA服务更加关注场景能力，即关注服务在业务流程中的节点；关注功能描述与输入输出；关注服务的是否被依赖以及被谁依赖。

     站在微服务的角度上来说，微服务是可以独立部署、独立运行，并且是关注完整功能的聚合。所以，微服务内部是应该包含业务主体的，并且包含围绕该业务主体的全部能力和业务逻辑，而且在微服务实例设计开发的层面也需要考虑微服务之间彼此的数据架构上的分离。

9.微服务治理的管理过程与管理领域

微服务治理包含以下的管理过程与管理领域：