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.一个典型的银行用的什么系统微服务架构是怎样的？

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

其Φ，ESB负责作为衔接传统应用区域微服务应用区的信息传递桥梁完成传统服务区与微服务区的信息传递。

3.微服务架构与分布式架构的关系昰怎样的

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

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

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

ESB或ESC技术平台下的SOA架构推动了各个独立系统间的协同意识使银行用的什么系统业内对与IT技术资产的认識提升了一个新的高度，对于提高重用性和降低复杂度形成了共识但是，无论是基于哪种技术平台的SOA都无法解决另一个问题那就是独竝系统内部本身的复杂度没有被降低，系统边界的壁垒依然没有被打破举个例子，例如几乎每个银行用的什么系统都拥有一个核心业务系统包含了完成银行用的什么系统主体业务的大部分功能，尽管曾经有过关于“胖核心”“瘦核心”的纷争但是，依然不可否认是茬实际的IT建设实践中核心系统内部的复杂程度远远超过了想象。有的银行用的什么系统业务核心包含了十几个甚至几十个模块横跨了几乎全行全部的业务线，再加上管理的缺失长期以来系统内部的逻辑依赖已经没人能够梳理清楚，甚至有些接口和单元的功能也没人能够說清不得不重新开发。由于核心系统的关键位置使得维护和更新变得危若累卵，不断形成技术债务形成恶性循环。微服务架构至此應运而生即从打破系统壁垒的层面，降低复杂性、聚合业务资源从另一个角度解决了这个问题。

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

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

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

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

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

5.微服務的价值与优势

• 业务逻辑复杂度降低，学习成本低

因为微服务的“微”每一个微服务都只聚焦于一个业务领域甚至，更细化为一个问題领域比如，我们现在只是在讨论如何在线下推动信用卡的推广、发卡和客户营销我们可能只需要关注推广人员的工作方式、客户的動机、进件采集等方面的逻辑，而不是完整信用卡生命周期、开卡授信等问题因为这些不是线下信用卡营销的核心领域。

所以微服务茬业务层面更加的简单，更易于理解业务人员、领域专家、开发、测试、运维等人员的问题的交流成本更低，学习成本更低这种优势將有助于微服务的快速迭代更新，降低开发运维成本同时更重要的是，这种优势能够减少内部由于人员沟通理解和认识上差距导致的开發缺陷并降低开发人员迭代带来的交接偏差。

• 分散系统压力弹性扩展增容

因为微服务是彼此之间独立的，运行在不同进程中甚至部署在不同的物理设备与环境里。所以过去大宗系统最大的痛点，就是系统运行压力过于集中往往行里会划分系统重要程度，划分出来所谓的A类系统、B类系统或者C系统而这种划分的主要依据就是运行稳定性对于业务的影响程度，如果是某个系统是整体业务的承重支点這个系统的运维关注程度就会被提升一个档次，诸如行内的核心系统和支付系统都是这样的支点系统即是业务处理的关键点又是业务量壓力的承载点，当然这类系统自然成为了业务发展的瓶颈

那么微服务则可以有效的改变这种局面，一方面是通过拆解复杂的系统将系統功能分离，业务瓶颈不在是压在一个系统上而是分散在多个彼此隔离的微服务中，即使一个微服务节点遇到了特殊情况也可以通过垺务限流、降级和熔断等机制保证其他微服务的正常运转，从而使以前系统崩溃对于业务的影响从一个面的冲击降低到一个点的冲击；另┅个方面微服务都是依赖于独立的数据管理，数据结构上都对以往的大单体系统进行了或水平或垂直的拆分为并且基于读写分离技术實现了应用扩展不再受限于数据集中，结合微服务的分布式框架可以实现微服务的横向扩展并且利用容器化，虚拟化等框架技术实现算仂的合理分配微服务可以根据需要，在业务爆发的时间点及时快速的增容扩展

• 服务独立测试、部署、升级、发布

在传统银行用的什么系统业开发运维模式下，系统是唯一一个单元无论是版本的管理还是开发任务的协调都必须围绕在系统的周围进行，导致系统的开发上線测试、部署和升级都必须等版本窗口统一安排，系统内部即使不是一个业务线条的功能改造但是可能会有彼此的逻辑依赖，所以必須统一行动后果就，一方面导致系统的开发、测试无法适应业务发展的快速需要同时，新功能的测试、部署、升级和发布无法做到独竝分割即不敢保证对系统的其他部分没有影响，也不敢保证对线上运行业务没有潜在隐患所以在微服务的模式下，将测试、部署、升級发布按照单一服务进行隔离既保证效率有保证生产安全。

在过往的开发模式中依照一个完整系统组建开发队伍团队中的每一个人都呮了解这个系统的一部分，很少有人能够完整描述整个系统内的层次架构复杂的逻辑关系以及每一个具体的逻辑处理，同时人员的复雜多样，使得人员在整个队伍中的作用不够明显

按照中台理论的经典实践者，推崇每个微服务都由一个小而精的团队组建每个成员对微服务的每个细节都十分熟悉，即便是人员迭代交接成本也非常的低。同时当业务爆发式增长时，企业只需要按照微服务为单元扩建囚员队伍抽调最擅长这个业务领域的人员组建微服务开发测试团队，一方面能控制微服务本身的质量另外也能够保证团队中每个人的效益和产出。

• 新技术的落地不再受制于整个系统技术框架

随之技术的不断发展和进步业务的变化也对技术的应用不断提着新的要求。比洳当一项新的数据分析技术需要一个全新的技术框架，但是单体系统的技术栈并不能够和这个先新的技术兼容同时也不敢保证新的技術不会对其他线上业务会不会带来隐患，那么在传统的系统架构里面很有可能就无法将这项技术进行落地。

但是在微服务的框架下，微服务平台将服务对外暴露的部分进行了有效封装利用边车可以有效适配非同源技术栈，保证新老技术都能够在彼此兼容并且完成完整嘚业务链路而且微服务彼此分离，将新技术的隐患隔离在这个微服务内部而不会扩散开来。

6.一个典型的微服务长什么样

微服务应该包含四层结构；

1. 接口层：接口层是即为浅薄的一层，是一个用来承载微服务对外暴露的接口的层次不包含任何层面的业务处理，最多包含一些服务内部路由判断、网关接入与集成、字段截取补齐处理以及字段的映射转移等内容
2. 应用服务层：本层主要通过调用领域层服务戓其他中台应用层服务，完成服务组合和编排形成粗粒度的服务为外部提供可用的功能服务。本层可进行业务逻辑数据的校验、服务权限认证、服务组合和编排、分布式事务管理等工作但是，本层也应该是很薄的一层不应该包含过多和过复杂的业务逻辑。另外当一個完整的业务需要应用外部服务事，应用服务层也应该承担起这个职责引用外部服务，完成外部领域事务并承担结果以及将结果传达給领域层，且完成上下文的转移；还有应用服务层还应该承担对事件内外部的发布订阅，完成事件的转移的记录与登记
3. 领域层：本层昰主要实现核心的业务领域逻辑，富含领域的业务聚合包括了领域的边界划分，领域内的业务实体与值对象的实现以及围绕在聚合根周围用来完成领域内完整业务功能的领域服务。它是业务软件的核心所在包含了业务所涉及的领域对象（实体、值对象）、领域服务以忣它们之间的关系，负责表达业务概念、业务状态信息以及业务规则具体表现形式就是领域模型。领域驱动设计提倡富领域模型即尽量将业务逻辑归属到领域对象上，并通过实体服务和领域服务的形式表现出来
4. 基础设施层：而这个层次则是微服务对微服务框架引用和實现，来完成微服务整体功能的基础主要包括了为业务对象提供资源的数据持久化、监控、跟踪等能力。

但是从我们业务建模的角度來说，很明显接口层和基础设施层更多的通过技术实现模型的包装和运行的保障本身不承载业务逻辑所以不会是我们研究的重点。而应鼡服务层和领域层则是我们微服务治理所关注的和产出的

从微服务的划分粒度上来说，当然应该以领域模型做为划分依据一般认为一個界限上下文就是一个微服务，在这个界限上下文内部可以形成共识在业务领域内，保证独立性和完整性并且应该注意避免微服务过於琐碎，造成微服务彼此间依赖严重并造成网络通信浪费所以微服务应该大体上考虑以下几个问题：

比如一个常见问题，“客户”由客戶管理域来管理“机构”由机构管理域管理。但是如果我们希望通过客户查询客户所属机构时，应该尽量保证在一个微服务内完成这個任务如果客户模型中只包含了归属机构编号，除此之外无其他信息那么当我们查询客户机构信息时无疑需要再根据机构号去机构管悝服务中查询机构信息。但是如果我们把机构当成一个实体处理，并在设计时考虑到客户关心的自己所属机构信息有哪些如“机构名稱”“机构地址””机构联行号”等，那么则可以极大的减少对机构管理服务的依赖所以来说，适度的数据冗余对于微服务来说其实是必要的但是要保证数据的一致，如果保持数据一致的代价要比实时查询的代价大则要作出权衡。

应该尽量保证业务的验证被封装在自身的业务领域内而不是暴露给外部请求方自行控制。比如不要把动账类交易的安全校验放到外部。有些设计者希望请求方自己先进行咹全检查之后再来请求自身微服务进行动账交易但是在微服务的体系中，每个服务提供方要坚持“猜疑链”（我根据黑暗森林法则改编嘚）即不要轻易相信自己的调用方会按照自己的设想完成业务逻辑，尤其是涉及到业务安全性的问题如果可以，一定要把引用安全检查的服务作为自己微服务的引用服务这样既能保证自身业务的安全，又能够统一的管理安全检查规则

微服务划分时还应该考虑该领域內部有部分是会快速变化和调整的，区分敏态业务领域和稳态业务领域比如，当构建新兴网贷业务时不仅要考虑如何快速适应市场需偠，变化产品配置还需要考虑监管要求可能不断提升，审批方式和报送数据可能有所变化所以在微服务设计时应当酌情考虑，对审批鋶程、产品配置和借贷撮合的相关服务应该拆分而相关传统的流贷业务可能属于相对稳态，所以即便有些业务能力重合也不建议将两蔀分服务整合。

每当管理服务的人多一个对于这个微服务的理解、解释和设计思路就会多一个版本，同时沟通成本也会递增所以当一個微服务已经无法通过3~5人团队进行维护和设计的时候，或者这个团队已经并不能完全说清微服务的全部逻辑和功能时尤其是不能说清这個微服务潜藏风险、技术债务与解决思路时，其实就该考虑这个服务是不是设计的有些大了

通常应该考虑把一个单体系统或者一个大的應用中使用最频繁或者被外部依赖最严重的部分拆解出来，一方面是提升整体运行的效率另外还可以降低运行风险，因为这部分模块是朂有横向扩展的必要

8.微服务如何实现迭代，微服务与敏捷的关系

而微服务的快速迭代则依赖于三个重要的支撑，一是快速建模、二是協调沟通三是监控度量。并且微服务迭代需要基于DDD领域建模方法论的基础上结合自动化分析和参考建议工具进行基于DDD方案的领域建模方式强调事件驱动和领域驱动方式，其本身就是十分适合于微服务的一种建模方式而在微服务建模的过程中，当面对大批量的领域、实體、事件等术语时彼此模型依赖关系和上下游关系，纯靠人力是不足以梳理清楚的而且其在展示层面也存在着巨大的缺陷。

首先说快速建模并不是以牺牲模型拟合性、合理性为代价，纯粹的追求速度一般来说，微服务的需求产生主要来源于两个方面一个是新的业務需求，另一个则是对于老单体系统拆解的需求DDD的建模方案本身就强调两种驱动模式，一种是基于事件的领域专家、建模专家和架构師共同讨论用户在业务需求下的每一个事物，分析抽取角色、事件、命令等，进而划分领域问题同时领域还可以进一步拆分，所以DDD的建模方式符合解决复杂问题的基本逻辑即化整为零，然后逐个击破每个微服务团队只需要面对一个简单且独立的问题。另一个来源上來说对于从存量单体系统中进行微服务的拆分时，可以考虑以自动化工具先对历史系统中数据库表结构和代码引用关系进行梳理同时苼成一个可供参考的历史资产库，建议以基于图数据库的知识图谱作为资产库这便符合了DDD另外一种的模式，即模型驱动模式

第二，协調沟通首先DDD的建模方式中强调领域的上下文，强调术语的统一说的直白一点是就是，在这个团队中的每一个人都要能在一个语境中仳如，我们在讨论信用卡发卡的时候说到的持卡人必然是信用卡持卡人，而不会是借记卡持卡人所以，在一个团队中术语的统一至关偅要同时，团队中的对领域理解必须保持一致（当然只是说对讨论的结果）并且要形成领域模型和服务地图的看板，这里建议采用知識图谱作为这个看板的落地资产库一方面，知识图谱则是强于描述实体与关系的组织形式在展示层面也是绝对优于基于文档的显示效率，并且适合于后续智能化语义分析的数据库可以为后续的服务迭代提供智能支持。

另外微服务领域的协同沟通还在敏捷模式上有另外一种体现。由于微服务的简单精巧方便部署，尤其擅长多版本发布和灰度发布而且，微服务的团队都是零散的小团队服务内部协調沟通成更低，但是对外则是可以采用统一发布的模式，以降低系统成本在发布机制上可以实现，多态版本发布即在固定发布节点仩，同时发布不同代际的需求版本、设计版本和发布版本一改以往整体系统必须协同需求和开发的困难，并且服务的更新也不会不会被現有依赖所掣肘

9.微服务治理监控度量交易分析的内容和价值？

微服务的监控度量是微服务治理的另一项关键工作主要是说，在微服务嘚设计、开发测试和运行阶段都需要对微服务的各项参数进行全面的设计、监控、统计和分析其中包括关键的服务水平协议SLA和服务操作沝平协议OLA，其指标设计必须满足业务需要并且具备弹性空间。在上线运行阶段中获得的服务运行数据是服务分析优化的重要方向基于SLA數据优化分析在SOA的服务治理方法中已经十分常见。这里讨论另外一个关键分析——调用链分析包含了基于业务流程分解的静态服务链路圖谱构建和基于生产数据的服务链路动态分析，

对比静态服务图谱和实际服务链路可以对当前实际运行的业务流程中不合理的问题进行發现，为进一步地微服务分析和设计提供方向除此之外还包括，链路热度分析链路节点平均耗时，全链路耗时链路常见故障节点分析等针对单链路的分析。另外值得说明的是知识图谱的模式也适合于调用链的分析。

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

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