当前位置：文档库 › 微服务架构设计V1

微服务架构设计V1

微服务架构设计

一、微服务架构介绍 (3)

二、微服务出现和发展 (3)

三、传统开发模式和微服务的区别 (4)

四、微服务的具体特征 (7)

五、SOA和微服务的区别 (9)

六、怎么具体实践微服务 (11)

七、常见的设计模式和应用 (17)

八、优点和缺点 (23)

九、思考：意识的转变 (26)

一、微服务架构介绍

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的

类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

二、微服务出现和发展

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；

越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。

这老头是个奇人，特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词，都有一个特点：一解释就懂，一问就不知，一讨论就打架。

Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks 公司的首

席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的

专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集

成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几

本经典书籍：《企业应用架构模式》、《UML精粹》和《重构》等。

————百度百科

三、传统开发模式和微服务的区别

先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（单体式开发）。

所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了DO/DAO，Service，UI等所有逻辑。

优点：

①开发简单，集中式管理

②基本不会重复开发

③功能都在本地，没有分布式的管理和调用消耗

缺点：

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断

2、维护难：代码功功能耦合在一起，新人不知道何从下手

3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉

5、扩展性不够：无法满足高并发下的业务需求

常见的系统架构遵循的三个标准和业务驱动力：

1、提高敏捷性：及时响应业务需求，促进企业发展

2、提升用户体验：提升用户体验，减少用户流失

3、降低成本：降低增加产品、客户或业务方案的成本

基于微服务架构的设计：

目的：有效的拆分应用，实现敏捷开发和部署

关于微服务的一个形象表达：

X轴：运行多个负载均衡器之后的运行实例Y轴：将应用进一步分解为微服务（分库）Z轴：大数据量时，将服务分区（分表）

四、微服务的具体特征

官方的定义：

1、一些列的独立的服务共同组成系统

2、单独部署，跑在自己的进程中

3、每个服务为独立的业务开发

4、分布式管理

5、非常强调隔离性

大概的标准：

1、分布式服务组成的系统

2、按照业务，而不是技术来划分组织

3、做有生命的产品而不是项目

4、强服务个体和弱通信（Smart endpoints and dumb pipes ）

5、自动化运维（DevOps ）

6、高度容错性

7、快速演化和迭代

五、SOA和微服务的区别

1、SOA喜欢重用，微服务喜欢重写

SOA的主要目的是为了企业各个系统更加容易地融合在一起。说到SOA不得不说ESB(EnterpriseService Bus)。ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。

通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成SOAP 1.2等等。它还可以把一个服务路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。各服务间可能有复杂的依赖关系。

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，

而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

2、SOA喜欢水平服务，微服务喜欢垂直服务

SOA设计喜欢给服务分层(如Service Layers模式)。我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。这种设计要求所有的服务都通过这个Entity服务层

来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的data store。我们在拆分数据库时可以适当的做些

去范式化(denormalization)，让它不需要依赖其他服务的数据。

微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。在SOA设计模式中这种情况通常会用到Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。

3、SOA喜欢自上而下，微服务喜欢自下而上

SOA架构在设计开始时会先定义好服务合同(service contract)。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。它使用Enterprise

Inventory和Service Composition等方法来集中管理服务。SOA架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。SOA架构适用于TOGAF之类的架构方法论。

微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。

六、怎么具体实践微服务

要实际的应用微服务，需要解决一下四点问题：

1、客户端如何访问这些服务

2、每个服务之间如何通信

3、如此多的服务，如何实现？

4、服务挂了，如何解决？（备份方案，应急处理机制）

1、客户端如何访问这些服务

原来的Monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的Java进程了。客户端UI如何访问他的？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。

另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括：①提供统一服务入口，让微服务对前台透明

②聚合后台的服务，节省流量，提升性能

③提供安全，过滤，流控等API管理功能

其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是

移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

用过Taobao Open Platform（淘宝开放平台）的就能很容易的体会，TAO就是这个API Gateway。

2、每个服务之间如何通信

所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式：

同步调用：

①REST（JAX-RS，Spring Boot）

②RPC（Thrift, Dubbo）

异步消息调用(Kafka, Notify, MetaQ)

同步和异步的区别：

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意思的话题。

一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的

SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，

他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的

服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息

发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，

对broker分布式管理也是一个很大的挑战。

3、如此多的服务，如何实现？

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？

这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息

注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK 寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。

当服务下线时，ZK会发通知给服务客户端。

客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

4、服务挂了，如何解决

前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，

不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

①重试机制

②限流

③熔断机制

④负载均衡

⑤降级（本地缓存）

这些方法基本都很明确通用，比如Netflix的Hystrix：https://https://www.wendangku.net/doc/271494842.html,/Netflix/Hystrix

七、常见的设计模式和应用

有一个图非常好的总结微服务架构需要考虑的问题，包括：

1、API Gateway

2、服务间调用

3、服务发现

4、服务容错

5、服务部署

6、数据调用

六种常见的微服务架构设计模式：1、聚合器微服务设计模式

这是一种最常见也最简单的设计模式：

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步

发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2、代理微服务设计模式

这是聚合模式的一个变种，如下图所示：

在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

3、链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应，如下图所示：

基于SpringCloud 微服务系统设计方案

微服务系统设计方案 1.微服务本质微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。理解微服务架构和理念是核心。 2.系统环境

3.微服务架构的挑战可靠性：由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。也就是没有充分的保障机制，则单点故障会大量增加。运维要求高：系统监控、高可用性、自动化技术分布式复杂性：网络延迟、系统容错、分布式事务部署依赖性强：服务依赖、多版本问题性能（服务间通讯成本高）：无状态性、进程间调用、跨网络调用数据一致性：分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。重复开发：微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。

微服务架构的部署

微服务架构的部署本文从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。最后，将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求，进一步理清本项目所实现的容器服务管理平台的完善性需求。本项目是一个企业级的容器服务管理平台，该平台的功能是基于容器实现的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境，提高微服务架构下的开发和运维效率。项目的开发背景如下：首先，该系统具有典型分布式应用系统特征：该平台所运行的服务器配置不高，例如华为RH1288这类低配置服务器，允许硬件失败；系统平台要求可根据实际用户数的规模进行伸缩部署，保证硬件资源的合理利用；由于系统平台之上需要运行若干企业应用的开发和运行环境，可靠性是非常重要的，不允许单点失效。其次，本系统功能复杂，从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言，由不同的开发小组完成。第三，项目组成员由几个城市的异地团队协同开发，统一的开发环境和协同工具是必不可少的。针对上述项目背景的考虑，本项目选择基于微服务架构进行项目开发。开发、测试、部署使用到的工具集 “工欲善其事、必先利其器”，借助适合的流程和相关工具集，才能提高微服务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理，提高开发、测试、部署的效率。代码库：本项目使用分布式代码库Gitlab，它的功能不限于代码仓库，还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能，是代码管理和异地团队沟通、协作工具的首选。 Docker镜像仓库、Docker：本项目用容器贯穿整个软件开发流程，以容器作为应用发布的载体，应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势，目前国内外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生产环境中了。

微服务架构设计与实战

关于举办“微服务架构设计与实战”高级培训班的通知各有关单位：作为一种新的设计和架构理念，微服务自2014年首次提出就引发了业界激烈的讨论。同时，Docker技术的迅速发展，也让微服务架构的实施变得更加容易。相比于传统的单体式应用而言，微服务这种小而化之、互相连接的设计理念不仅能让复杂应用的构建变得更加灵活，更能帮助创业企业在面对市场的高度不确定性时，快速推出新产品，低成本试错。那么，企业究竟该如何去设计、开发和部署微服务到自己的业务中去?如何做好服务发现和服务治理呢?中国软件产业培训网决定在举办“微服务架构设计与实战培训班”望各单位收到通知后组织相关人员参加。现将有关事宜通知如下：一、培训时间及地点 2019年12月20日-12月23日北京 2020年01月10日-01月13日上海二、主讲专家程老师 CTO，微服务架构首席咨询师，国内较早倡导和实践微服务的先行者，多次受邀在大型技术会议主题分享“微服务架构”相关主题。超过10年以上的软件行业经验,从企业应用、互联网应用、服务化平台的架构设计、开发到自动化构建、持续集成、持续交付以及DevOps 的转型实施等有较丰富的实践经验。范老师国内架构设计专家、多领域架构评审委员和技术架构组委员。信息技术领域具有坚实的学术背景和教学培训经验，多年研发和客户项目高级管理咨询能力，多年包括华为IPD 研发管理工作经历。善于用先进信息化技术架构和方法指导团队完成设计工作，具有雄厚的咨询能力。具有大型分布式团队的领导和管理经验。三、培训特色 1. 理论与实践相结合、案例分析与行业应用穿插进行; 2. 专家精彩内容解析、学员专题讨论、分组研究;

微服务架构设计V1

微服务架构设计

目录一、微服务架构介绍 (3) 二、微服务出现和发展 (3) 三、传统开发模式和微服务的区别 (4) 四、微服务的具体特征 (7) 五、SOA和微服务的区别 (9) 六、怎么具体实践微服务 (11) 七、常见的设计模式和应用 (17) 八、优点和缺点 (23) 九、思考：意识的转变 (26)

一、微服务架构介绍微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。二、微服务出现和发展微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。这老头是个奇人，特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词，都有一个特点：一解释就懂，一问就不知，一讨论就打架。

微服务框架的设计与实现

微服务框架的设计与实现① 张晶1, 黄小锋2, 李春阳3 1(北京中电普华信息技术有限公司, 北京100192) 2(中国电建集团国际工程有限公司, 北京100048) 3(国网信息通信产业集团有限公司, 北京100031) 摘要: 相对于传统单块架构, 微服务框架具有技术选型灵活, 独立部署, 按需独立扩展等优点, 更适合当前互联网时代需求. 但微服务架构的使用引入了新的问题, 如服务注册发现、服务容错等. 对微服务框架引入的问题进行分析, 并给出了微服务框架的一种实现方案, 在框架层面解决服务注册发现、服务容错等共性问题, 使业务系统开发人员专注于业务逻辑实现, 简化系统开发的难度, 提高开发效率. 关键词: 微服务框架; 服务注册; 服务发现; 服务容错 Design and Implementation of Microservice Architecture ZHANG Jing1, HUANG Xiao-Feng2, LI Chun-Yang3 1(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China) 2(PowerChina International Group Limited, Beijing 100048, China) 3(State Grid Information & Telecommunication Industry Group Co. Ltd., Beijing 100031, China) Abstract: Compared with traditional single block architecture, microservice architecture has many advantages, such as flexible technology selection, independent deployment, and independent scalability more suitability for the current needs of the internet age, etc. But microservice architecture also introduces new problems such as service registration, service discovery, service fault tolerance. On the basis of the analysis for problems mentioned above, this paper proposes one implementation of microservice framework, which can solve service registration, service discovery, service fault tolerance and other common problems. Based on this, developers only need to focus on the development of business functions, so that it can simplify the difficulty of system development and improve development effectiveness. Key words: microservice architecture; service registration; service discover; fault tolerance 传统信息化系统的典型架构是单块架构(Monolithic Architecture), 即将应用程序的所有功能都打包成一个应用, 每个应用是最小的交付和部署单元, 应用部署后运行在同一进程中. 单块架构应用具有IDE友好、易于测试和部署等优势, 但是, 随着互联网的迅速发展, 单块架构临着越来越多的挑战, 主要表现在维护成本高、持续交付周期长、可伸缩性差等方面[1]. 微服务架构(Microservices)的出现以及在国内外的成功应用, 成为系统架构的一种新选择. 很多大型宝等都已经从传统单块架构迁移到微服务架构[2]. 微服务架构提倡将单块架构的应用划分成一组小的服务, 互联网公司如Twitter、Netflix、Amazon 、eBay、淘服务之间互相协调、互相配合, 为用户提供最终价值. 1 微服务架构微服务架构是一种架构模式, 采用一组服务的方式来构建一个应用, 服务独立部署在不同的进程中, 不同服务通过一些轻量级交互机制来通信, 例如RPC、HTTP等, 服务可独立扩展伸缩, 每个服务定义了明确的边界, 不同的服务甚至可以采用不同的编程语言来实现, 由独立的团队来维护[3]. 相对于传统的单体应用架构, 微服务架构具有单个服务易于开发、理解和维护; 复杂度可控; 技术选 ①收稿时间:2016-09-18;收到修改稿时间:2016-11-03 [doi: 10.15888/https://www.wendangku.net/doc/271494842.html,ki.csa.005796]

微服务架构落地最佳实践

难点1：“一步到位”的认知错觉这些年微服务大红大紫，但是真正能够拿出来做为可实践的案例少之又少。大部分的微服务案例只能看到微服务架构的“演进结果”，但是看不到微服务架构的“演进过程”。这就像每个人看到一个架构的高峰，却没有看到攀登高峰的路径。这就给很多架构师一个假象：微服务的架构是通过能力极高的架构师一步到位设计出来的。这和很多团队自上而下的架构设计感受和相似。于是架构师们蜂拥而至，各种分析方法论层出不穷，讨论和分享络绎不绝。然而真正落地实施的却很少，使得微服务在网络上慢慢变成了一种“玄学”：微服务的实施在“理论研究”的阶段。这违反了软件架构的最基本规律：架构是解决当前的需求和痛点演进的，而无法对没有出现的问题和痛点进行设计。因此，一步到位的整体的微服务架构设计完全没有必要。况且一个集中化的设计，很难体现微服务的轻量级优势。我相信技术的发展一定是向不断降低成本的方向上发展的。如果新技术没有降低成本反而提升了成本，要么这个新技术有问题，要么一定是姿势不对，走错了路。因此，准备实施微服务一定要有一个长期的思想准备。不过跨过了最初的门槛之后，剩下的工作可以被复制而且速度会越来越快。难点2：“架构师精英主义”

很多产品对架构师的依赖很大，即“架构师精英主义”：认为产品架构只有这个组织的“技术精英”——架构师才可以完成，而团队其它成员只需要实现架构师的设计就可以。这是大型企业和大型系统的常见问题，这来源于长期的重量级企业级架构习惯。而微服务则类似于一种“敏捷边际革命”：即由一个不超过2~8个人的小团队就可以完成的功能。而且这种规模的团队即使从整个产品团队移除也对整体产品的研发进度没有影响。因此，即使失败了不会带来太多的损失。不过，当第一个微服务改造成功，那么成功经验的复制带来的乘数效应却能带来很大的收益。从架构改造投资的风险收益比来看，这是非常划算的。因此，微服务团队完全没必要大张旗鼓，只需要两三个人就可以动工。但是，谁也没有微服务的实践经验啊，万一失败了怎么办？这就带来了下一个难点。难点3：缺乏一个信任并鼓励创新的环境

微服务系统和数据库设计方案

微服务系统和数据库设计方案 1.微服务本质微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。理解微服务架构和理念是核心。 2.系统环境

论微服务架构及其应用

论微服务架构及其应用摘要 2016年7月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作，该项目是基于互联网，为单位、企业和个人等公众群体提供7*24小时的查询申请服务，同时兼顾行贿犯罪预防宣传。本文结合作者的实践，以行贿犯罪档案互联网查询系统为例，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该系统是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。经过项目组近一年的努力，本产品已顺利开发完成，目前，已在浙江、云南等多省上线使用，取得客户和公司领导的一致好评。正文近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式(Microservice Architecture Pattern)逐渐流行。它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通信协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。 2015年7月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作。本文结合作者的实践，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该架构是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。

微服务架构设计方案

引言：“微服务”是当前软件架构领域非常热门的词汇，能找到很多关于微服务的定义、准则，以及如何从微服务中获益的文章，在企业的实践中去应用“微服务”的资源却很少。本篇文章中，会介绍微服务架构（Microservices Architecture）的基础概念，以及如何在实践中具体应用。 1.单体架构(Monolithic Architecture ) 企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。单体架构的初期效率很高，应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新功能，然后开发许多新代码，随着时间推移，这个简单的应用会变成了一个巨大的怪物。图1：单体架构大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。

单体架构的应用一般有以下特点： ?设计、开发、部署为一个单独的单元。 ?会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难 ?很难以敏捷研发模式进行开发和发布 ?部分更新，都需要重新部署整个应用 ?水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难（部分服务需要更多的计算资源，部分需要更多内存资源） ?可用性：一个服务的不稳定会导致整个应用出问题 ?创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上 2.微服务架构（Microservices Architecture）微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。多数人对于微服务的定义是，把本来运行在单体架构中的服务拆分成相互独立的服务，并运行在各自的进程中。在我看来，不仅如此。最关键的地方在于，不同的服务能依据不同的业务需求，构建的不同的技术架构之上，并且聚焦在有限的业务功能之上。因此，在线零售网站可以用图2的微服务架构来简单概括。基于业务需求，需要增加一个账户服务微服务，因此构建微服务绝不是在单体架构中把服务拆分开这么简单。

微服务架构的部署

微服务架构10个最重要的设计模式

微服务架构10个最重要的设计模式自从软件开发的早期(1960年代)以来，解决大型软件系统中的复杂性一直是一项艰巨的任务。多年来，软件工程师和架构师为解决软件系统的复杂性进行了许多尝试：David Parnas的模块化和信息隐藏(1972)，Edsger W. Dijkstra的关注分离(1974)，面向服务的体系结构(1998)。他们所有人都使用了久经考验的成熟技术来解决大型系统的复杂性：分而治之。自2010年代以来，这些技术不足以解决Web规模应用程序或现代大型企业应用程序的复杂性。结果，架构师和工程师开发了一种新方法来解决现代软件系统的复杂性：微服务架构。它也使用了相同的旧"分而治之"技术，尽管采用了新颖的方式。软件设计模式是解决软件设计中常见问题的通用，可重用的解决方案。设计模式可帮助我们共享通用词汇，并使用经过实战检验的解决方案，而不是重新发明轮子。今天描述的是一组设计模式，以帮助您实现这些最佳实践。本文主要内容： ·微服务架构 ·微服务架构的优势 ·微服务架构的缺点 ·何时使用微服务架构 ·微服务架构设计模式请注意，此清单的大多数设计模式都有几种上下文，可以在非微服务体系结构中使用。但是我将在微服务架构的背景下对其进行描述。微服务架构

微服务体系结构：简要概述以及为什么要在下一个项目中使用它以及模块化单片软件体系结构真的死了吗? 我的微服务架构定义是：微服务架构旨在将大型，复杂的系统垂直(按功能或业务要求)划分为较小的子系统，这些子系统属于流程(因此可独立部署)，并且这些子系统之间通过与语言无关的轻量级网络通信相互通信(例如REST，gRPC)或异步(通过消息传递)方式。这是具有微服务架构的业务Web应用程序的组件视图： > Microservice Architecture by Md Kamaruzzaman 微服务架构的重要特征： ·整个应用程序分为多个单独的进程，每个进程可以包含多个内部模块。 ·与模块化Monoliths或SOA相反，微服务应用程序是垂直拆分的(根据业务能力或领域)微服务边界是外部的。结果，微服务通过网络调用(RPC或消息)相互通信。 ·由于微服务是独立的流程，因此它们可以独立部署。他们以轻巧的方式交流，不需要任何智能交流渠道。微服务架构的优势： ·更好的开发规模。 ·更高的发展速度。 ·支持迭代或增量现代化。 ·充分利用现代软件开发生态系统(云，容器，DevOps，无服务器)的优势。 ·支持水平缩放和粒度缩放。

微服务技术调研与实践

微服务技术调研与实践微服务架构简介微服务架构模式（Microservices Architecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。微服务（micro services）这个概念不是新概念，很多公司已经在实践了，例如亚马逊、Google、FaceBook，在国内我自己知道的有：BAT、滴滴、饿了么、携程、唯品会、酷狗等公司。一个单体应用可能是下图这样的架构，各个功能在应用内部通过模块划分，这样的应用有它自己的好处如：调试简单、部署方便等。但是它也有明显的局限性，如：

不同模块发生资源冲突时无法解决（有些业务需要无阻塞的io操作，这明显使用nodejs之类的语音是非常棒的，但是有些业务需要做算法密集型的操作，这明显就是nodejs的短板，这时候单体应用就需要做一个妥协，而不能都取最优解）。单体应用一般所有应用都运行在同一进程中，在某个模块产生bug后会导致整个应用挂掉。其中最突出的是，随着时间的迁移这个应用会越来越大，会大到任何单个开发者都不可能搞懂它。将上图单体应用拆分为微服务的架构如下：从图中可以看到每一个模块功能都变成了一个单独的服务，各服务之间通过各自暴露的API 接口相互调用，对外的接口通过一个API GATEWAY 来统一处理。这种架构看起来明显是稍显复杂，但是其扩展性却是非常棒的，下图很好的描述如何去构建和扩展一个微服务架构。

X轴表示在物理层面做负载均衡、应用副本来提高吞吐能力。 Y轴表示从功能方面拆分服务，来对应处理单一专注功能。 Z轴表示如何通过优化路由来整合相关服务（API GATEWAY）微服务架构的优势与不足优点：每个服务足够内聚，足够小，代码容易理解、开发效率提高服务之间可以独立部署，微服务架构让持续部署成为可能；每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；容易扩大开发团队，可以针对每个服务（service）组件开发团队；提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；系统不会被长期限制在某个技术栈上。缺点

基于SpringCloud微服务系统设计方案

微服务系统设计方案 1. 微服务本质微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源APl。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。理解微服务架构和理念是核心。 2. 系统环境

3. 微服务架构的挑战可靠性：由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。也就是没有充分的保障机制，则单点故障会大量增加。运维要求高：系统监控、高可用性、自动化技术分布式复杂性：网络延迟、系统容错、分布式事务部署依赖性强：服务依赖、多版本问题性能（服务间通讯成本高）：无状态性、进程间调用、跨网络调用数据一致性：分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。重复开发：微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。

京东微服务平台架构设计

平台初心微服务组件平台是承载京东集团所有业务的服务调用、消息通知的底层架构平台、运维管理平台、知识分享平台、沟通协作平台和服务评价及诊断平台。底层架构平台由JSFRPC调用、JMQ消息服务及服务网格这三大基础通信技术构成，既能完成同步调用，又能完成异步消息通知，或者两者混合进行，兼容各种流行通信协议，并且支持跨语言，适用于各种线上及线下应用场景，满足了业务各式各样的通信要求，多年来包揽了集团几乎所有后台业务系统的通信流量，确保了集团各项业务的高效、平稳进行。随着集团对外赋能及组件化积木理论的提出，仅仅满足于“以底层架构平台充当通信管道”已经远远不能适应当前形势的发展。在对外赋能的过程中，不仅仅需要研发人员埋头苦干，还需要他们抬起头来站在全局角度来积极沟通、认真梳理业务领域知识，更需要产品经理、项目经理及各级决策者们跨体系、跨部门、跨业务的高效互动和协作，才能赢得对外赋能战略的真正成功。由此，微服务组件平台应运而生，它不仅连接了研发人员，而且还连接了广大产品经理、项目经理以及所有决策者们；它不仅提供了应用程序的通信管道，而且还提供了服务知识、信息交流的沟通管道；它不仅连接了京东内部团队，而且还连接了京东外部第三方；它不再“偏于底层技术建设”，而是不断向上延伸，发展到通过提供各种上层功能模块充分与应用场景、应用架构以及人相连接的“平台生态建设”上来。微服务组件平台的技术愿景：成为京东业务组件化及对外赋能的基石！平台组成

微服务组件平台作为一个生态系统，采用分层的设计模式，由许多相互支撑的模块共同组成。总体上说，微服务组件平台由三大部分组成：核心部分、生态工具链部分和基础数据服务部分。目前，平台正在按照计划有条不紊地推进，首期功能已经陆续上线。核心部分 ?基础设施层微服务架构大行其道的重要技术因素就是容器及容器编排系统的出现，JDOS作为京东容器集群平台，理所应当成为JSF最重要的基础设施；目前JSF所有的功能模块全部运行在容器上，而且还跟JDOS2.0进行了若干功能集成；未来JSF还将与JDOS进行更多、更深入的合作，为JSF打造一个坚实、稳定的技术底座。当然，我们也会和J-ONE/CAP这对基础设施组合进行合作，拓展平台的适应范围。 ?底层框架层该层是平台的基础层，包括了JSF SDK、京东服务网格（ContainerMesh）、服务发现机制（JSFRegistry）和JMQ；另外，我们接下来将着力打造全新的安全体系，全方位提升系统的安全性。 ?系统扩展层

企业微服务架构设计方案

企业微服务架构设计方案 ZeroCIceGrid、Spring Cloud、基于消息队列、Docker Swarm 微服务架构是当前很热门的一个概念，它不是凭空产生的，是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案，但业界已经有一些很有影响力的开源微服务架构平台，架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台，以此稳妥地实施项目的微服务化改造或开发进程。本文盘点了四种常用的微服务架构方案，分别是ZeroCIceGrid、Spring Cloud、基于消息队列与Docker Swarm。

ZeroCIceGrid微服务架构 ZeroCIceGrid作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能与分布式能力，如下所示是它的整体示意图。 IceGrid具备微服务架构的如下明显特征。首先，微服务架构需要一个集中的服务注册中心，以及某种服务发现机制。IceGrid服务注册采用XML文件来定义，其服务注册中心就是Ice Registry，这是一个独立的进程，并且提供了HA高可用机制；对应的服务发现机制就是命名查询服务，即LocatorService 提供的API，可以根据服务名查询对应的服务实例可用地址。

其次，微服务架构中的每个微服务通常会被部署为一个独立的进程，当无状态服务时，一般会由多个独立进程提供服务。对应在IceGrid里，一个IceBox就是一个单独的进程，当一个IceBox只封装一个Servant时，就是一个典型的微服务进程了。然后，微服务架构中通常都需要内嵌某种负载均衡机制。在IceGrid 里是通过客户端API 内嵌的负载均衡算法实现的，相对于采用中间件Proxy转发流量的方式，IceGrid的做法更加高效，但增加了平台开发的工作量与难度，因为采用各种语言的客户端都需要实现一遍负载均衡的算法逻辑。最后，一个好的微服务架构平台应该简化和方便应用部署。我们看到IceGrid提供了grid.xml来描述与定义一个基于微服务架构的Application，一个命令行工具一键部署这个Application，还提供了发布二进制程序的辅助工具——icepatch2。下图显示icepatch2的工作机制，icepatch2server类似于FTP Sever，用于存放要发布到每个Node上的二进制代码与配置文件，而位于每个Node上的icepatch2client则从icepatch2server 上拉取文件，这个过程中采用了压缩传输及差量传输等高级特性，以减少不必要的文件传输过程。客观地评价，在Docker技术之前，icepatch2这套做法还是很先进与完备的，也大大减少了分布式集群下微服务系统的运维工作量。

基于微信的微服务系统设计

Software Application ? 软件应用Electronic Technology & Software Engineering 电子技术与软件工程? 53【关键词】微服务微信小程序随着计算机技术、互联网技术以及智能终端日渐融入人们的日常生活，智能服务逐渐细化并逐渐聚焦成一个指定的业务功能或业务需求，此类细小服务功能单一、独立，但数量众多庞大。传统的服务系统由于开发成本高昂、开发技术难度较高、开发时间周期较长，严重地阻碍了智能服务系统为人们的日常生活提供服务，因此一种微服务新技术诞生于人们的日常生活服务。微服务系统能够被2到5人的小团队单独开发、支持不同的语言开发、允许容易且灵活的方式集成自动部署、易于被一个开发人员修改和维护、便于融入最新技术、能部署在中低端配置的服务器上、拥有独立的存储能力和数据库，由此可见，微服务系统具有开发和运维成本低、服务器性能要求较低、便于融入新技术等诸多优势。截止目前，较成熟的微服务开发平台主要为微信、支付宝、米家，其中微信平台技术程度相对较高，因此本文对基于微信的微服务系统设计展开了研究。1 微服务研究微服务指的是单个小型化的业务功能服务，每个微服务都有独立处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务系统是一种松耦合的面向服务架构，与紧耦合服务架构不同，开发或修改不需要对每个服务都进行开发或修改，因此微服务架构具备主要特点具备组件化、松耦合、自治、去中心化等优势。通过对微服务系统结构的特性分析可知，微服务聚焦一个指定的小型业务功能或业务需求，系统开发效率高，集中式管理，代码维护易，部署灵活，构建时间短，稳定性高。随着持续交付概念推广以及Docker 容器普及，微服务将这两种理念和技术结合起来，形成新的“微服务+API +平台”的开发模式，提出了容器化微服务的持续交付概念。微服务促进了DevOps 方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划基于微信的微服务系统设计文/李丹丹分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API 交互，做到了松耦合隔绝。（1）需要考虑构建DevOps 能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源。（2）保持微服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化。（3）保持团队和架构对齐，微服务通过技术层面的变革，对团队结构和组织文化有很强的要求和影响，识别和构建匹配架构的团队是解决问题的一大支柱。（4）打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进、持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现“快速响应”的初衷。2 基于微信的微服务系统设计基于微信平台所设计的微服务系统采用B/S 结构，微信用户借助微信小程序访问微系统，B 端为微信小程序，S 端为微服务系统。微信小程序将用户行为信息封装为微信消息数据上传至微信服务平台，微信服务平台通过对微信消息数据的解析、处理与封装，借助广域网将其转至微服务系统，微服务系统根据消息指令快速作出响应。基于上述分析可知，前端微信小程序与中间层微信服务平台之间通过API 实现信息传递，微信服务平台与后端微服务系统之间通过API 实现信息交互。如果这些命令是微信消息格式的命令，就会通过微信服务器转发到对应的公众号托管接口上，由反向代理服务器通过微信通信接口服务器来处理。如果这些命令是Web 形式的页面请求，微信客户端将会通过内置的浏览器直接向反向代理服务器发送请求，反向代理服务器检索其所请求的公众号服务所在的Web 应用服务器，然后由对应的Web 应用服务器对该请求作出响应，由此可见，此种模式是一种将持续交付概念和Docker 容器相结合的“微服务+API +平台”的开发模式，所设计的微服务系统如图1所示。3 结论本文先对微服务展开了研究，微服务聚焦一个指定的小型业务功能或业务需求，系统开发效率高，集中式管理，代码维护易，部署灵活，构建时间短，稳定性高。根据持续交付概念与Docker 容器相结合的“微服务+API +平台”的开发模式，本文设计了一套由微信小程序、微信服务平台、后端微服务系统组成的微服务系统。参考文献[1]吴坤安,黄文思,韩泽华等.基于Docker 的数据库微服务系统设计与实现[J].国外电子测量技术,2017(12):57-62.[2]黄嘉诚,董晶.基于微服务的智能档案服务系统设计与实现[J].电子设计工程,2018,26(02):26-30.[3]张晶,王琰洁,黄小锋.一种微服务框架的实现[J].计算机系统应用,2017,26(04):82-86.作者简介李丹丹(1989-)，男,河北省石家庄市人。大学本科学历。工程师。研究方向为微服务系统设计。作者单位北京网御星云信息技术有限公司北京市 100193图1：基于微信设计的微服务系统

可容错的微服务架构设计

可容错的微服务架构设计微服务架构可以通过明确定义的服务边界来隔离故障。但是像在每个分布式系统中一样，发生网络、硬件、应用级别的错误都是很常见的。由于服务依赖关系，任何组件可能暂时无法提供服务。为了尽量减少部分中断的影响，我们需要构建容错服务，来优雅地处理这些中断的响应结果。本文介绍了基于RisingStack 的Node.js 咨询和开发经验构建和操作高可用性微服务系统的最常见技术和架构模式。如果你不熟悉本文中的模式，那并不一定意味着你做错了。建立可靠的系统总是会带来额外的成本。微服务架构的风险微服务架构将应用程序逻辑移动到服务，并使用网络层在它们之间进行通信。这种通过网络间通信代替单应用程序内调用的做法，会带来额外的延迟，以及需要协调多个物理和逻辑组件的系统复杂度。分布式系统的复杂性增加也将导致更高的网络故障率。微服务体系结构的最大优势之一是，团队可以独立设计，开发和部署他们的服务。他们对服务的生命周期拥有完全的所有权。这也意味着团队无法控制他们依赖的服务，因为它更有可能由不同的团队管理。使用微服务架构，我们需要记住，提供者服务可能会临时不可用，由于其他人员发行的错误版本，配置以及其他更改等。优雅的服务降级微服务架构的最大优点之一是您可以隔离故障，并在当组件单独故障时，进行优雅的服务降级。例如，在中断期间，照片共享应用程序中的客户可能无法上传新图片，但仍可以浏览，编辑和共享其现有照片。

微服务容错隔离在大多数情况下，由于分布式系统中的应用程序相互依赖，因此很难实现这种优雅的服务降级，您需要应用几种故障转移的逻辑（其中一些将在本文后面介绍），以为暂时的故障和中断做准备。服务间彼此依赖，再没有故障转移逻辑下，服务全部失败。变更管理