竹磬网-邵珠庆の日记 生命只有一次，你可以用它来做些更多伟大的事情–Make the world a little better and easier

【架构设计】微服务的4大设计原则和19个解决方案

　　作者｜郝炎峰

编辑｜小智

本文将介绍微服务架构的演进、优缺点和微服务应用的设计原则，然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好的支撑企业应用架构。

注：本文转载自公众号 EAWorld，已获授权。

写在前面

微服务架构现在是谈到企业应用架构时必聊的话题，微服务之所以火热也是因为相对之前的应用开发方式有很多优点，如更灵活、更能适应现在需求快速变更的大环境。

微服务平台也是我目前正在参与的，还在研发过程中的平台产品，平台是以 SpringCloud 为基础，结合了普元多年来对企业应用的理解和产品的设计经验，逐步孵化的一个微服务应用平台。

微服务架构演进过程

近年来我们大家都体会到了互联网、移动互联带来的好处，作为 IT 从业者，在生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自自互联网的一些压力，那就是我们传统企业的 IT 建设也是迫切需要转型，需要面向外部客户，我们也需要应对外部环境的快速变化、需要快速创新，那么我们的 IT 架构也需要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。

我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产生的，最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的 SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速”。

微服务架构的好处

　　我们总结了四个方面的优点，分别如下：

是每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。

可以由一个小团队负责更专注专业，相应的也就更高效可靠。

微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

看到这里，大家会觉得微服务架构挺不错，然而还会有一些疑问，什么样的应用算是一个微服务架构的应用？该怎样设计一个微服务架构的应用？那我们来一起看看我们推荐的微服务应用的设计原则。

微服务应用 4 个设计原则

　　我们总结了四个原则推荐给大家：

AKF 拆分原则

前后端分离

无状态服务

Restful 通信风格

AKF 拆分原则

AKF 扩展立方体（参考《The Art of Scalability》），是一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。

Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。

前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如 JSP ，把 Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。

分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。

前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的 web UI 移动 App 等访问。

无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

Restful 通信风格

作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案 HTTPS 可用。

JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。

语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

当然在有些特殊业务场景下，也需要采用其他的 RPC 框架，如 thrift、avro-rpc、grpc。但绝大多数情况下 Restful 就足够用了。

微服务架构带来的问题

做到了前面讲的四个原则，那么就可以说是构建了一个微服务应用，感觉上也不复杂。但实际上微服务也不是个万金油，也是有利有弊的，接下来我们来看看引入微服务架构后带来的问题有哪些。

依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。

部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。

微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？

运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

上面这些问题我们应该都遇到过，并且也会有一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架； 实现统一认证、统一配置、统一日志框架、分布式汇总分析； 采用全局事务方案、采用异步模拟同步；搭建持续集成平台、统一监控平台等等。

这些解决方案折腾到最后终于搞明白了，原来我们是需要一个微服务应用平台才能整体性的解决这些问题。

微服务平台的 19 个落地实践

企业 IT 建设的三大基础环境

我们先来宏观的看一下，一个企业的 IT 建设非常重要的三大基础环境：团队协作环境、个人基础环境、IT 基础设施。

团队协作环境：主要是 DevOps 领域的范畴，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。

个人基础环境：就是本文介绍的微服务应用平台，他的目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。

IT 基础设施：就是我们通常说的各种运行环境支撑如 IaaS (VM 虚拟化) 和 CaaS (容器虚拟化) 等实现方式。

微服务应用平台总体架构

微服务应用平台的总体架构，主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分的。

开发集成：主要是搭建一个微服务平台需要具备的一些工具和仓库

运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微服务运行容器则会运行在这个平台之上。

监控治理：则是致力于在运行时能够对受管的微服务进行统一的监控、配置等能力。

服务网关： 则是负责与前端的 WEB 应用 移动 APP 等渠道集成，对前端请求进行认真鉴权，然后路由转发。

微服务应用平台的运行视图

参考上图，在运行期，作为一个微服务架构的平台与业务系统，除了业务应用本身外，还需要有接入服务、统一门户、基础服务等平台级服务来保障业务系统的可靠运行。图中的公共服务就是业务处理过程中需要用到的一些可选服务。

微服务平台的设计目标

微服务平台的主要目标主要就是要支撑微服务应用的全生命周期管理，从需求到设计开发测试，运行期的业务数据处理和应用的管理监控等，后续将从应用生命周期的几个重要阶段切入，结合前面提到的设计原则和问题，介绍平台提供的能力支撑情况。

微服务开发：前端、后端、混合

我们一起看一下我们正在开发中的微服务应用平台 EOS8.0 的一些开发工具截图，了解一下开发期提供了哪些关键的能力支撑。

前面的设计原则中提到了一个前后端分离的原则，那么我们的开发环境中，目前支持创建前端项目、后端项目和混合项目。其中前端项目、后端项目就对应前后端分离的原则，利用平台中集成的开发工具和框架可以做到前后端开发分离，利用持续集成工具可以方便的将前端、后端项目编译打包成可独立运行的程序。混合项目则是为了兼容传统模式而保留的，为企业应用向微服务架构演进提供过渡方案。

服务契约与 API 管理

对于前面提到的微服务带来的依赖管理问题，我们可以通过平台提供的 API 管理能力来解决。说到 API 管理，那首先就用提到服务契约。平台开发工具中提供了方便的服务发布能力，能够快速的将业务功能对外发布，生成服务的规格契约，当然也可以先设计服务契约，在根据契约来生成服务的默认实现代码。

这里强调一下，我们提到的服务契约是一个很重要的东西，他有点类似 web service 的 wsdl 描述，主要描述服务接口的输入输出规格标准和其他一些服务调用集成相关的规格内容。

　　服务契约与服务模拟

有了服务契约，我们就可以根据契约自动生成服务的文档和服务模拟测试环境，这样，开发者就可以方便的获取到依赖服务变更的情况，能够及时的根据依赖服务的变化调整自己的程序，并且能够方便的进行模拟测试验证。

根据契约生成模拟服务也就是我们常说的服务挡板，这样即使依赖的其他服务还无法提供功能，我们也可以通过挡板来进行联调测试。

服务契约与服务编排

有了服务契约，那就有了服务接口的输入输出规格，那么 restful 的服务编排也就变得可行。在我们设计的契约标准中，还定义了调用集成相关的内容，比如服务支持的事务模式等等。通过这些约定，我们就可以采用简单图形化的方式来对业务服务流程进行编排。编排能够很大程度上简化分布式服务调用的复杂度，如同步、异步、异步模拟同步、超时重试、事务补偿等，均有服务编排引擎完成，不再完全依赖老师傅的编码能力。

服务编排的作用和意义很大，可以快速的将已经提供的微服务能力进行组合发布，非常适合业务的快速创新。

但是大家要注意，逻辑流编排的是业务流程，尽量能够简单明了，一眼看上去就明白业务含义。而业务规则推荐采用服务内部进行编码实现。千万不要将我们的 “逻辑流” 图形化服务编排完全取代程序编码，这样就会可能会走入另外一个极端，比如设计出像蜘蛛网一样的逻辑流图，简直就是灾难。

微服务容器

我们再来看一下微服务运行容器的一个逻辑图，大家可以看到，我们要做微服务架构的应用，可靠高效的微服务应用，实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。

三方能力集成说明

我们的 API 管理契约文档 API 模拟我们是集成了 Swagger 的工具链。微服务应用平台的基础就是 SpringCloud，从容器框架到注册发现再到安全认证这些基础方案均采用了他的能力来支撑。下面简单看下我们集成的一些开源框架和工具。

SpringCloud 在微服务平台中的定位是基础框架，本文重点是要介绍一个企业级的微服务平台在落地过程中的一些设计原则和解决方案。具体 Spring Cloud 相关的技术就不在文中多做介绍了，大家可以在我们的公众号里面查看相关文章。

服务注册发现路由

接下来我们聊一下注册发现，以前的单块应用之间互相调用时配置个 IP 就行了，但在微服务架构下，服务提供者会有很多，手工配置 IP 地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。

我们的服务注册发现能力是依赖 SpringCloud Eureka 组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心，运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡期进行路由用。

一般情况，系统内微服务的调用都通过这种客户端负载的模式进行，否则就需要有很多的负载均衡进程。跨业务系统的服务调用，也可以采用这种去中心化的路由方式。当然采用 SOA 的模式，由中心化的服务网管来管理系统间的调用也是另一种选择，要结合企业的 IT 现状和需求来决定。

统一认证鉴权

安全认证方面，我们基于 Spring Security 结合 Auth2 再加上 JWT（Json web token）做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。后续在统一认证和权限方面我们产品会陆续推出较完善并且扩展性良好的微服务组件，可以作为微服务平台的公共的认证和鉴权服务。再啰嗦一句，认证鉴权一定是个公共的服务，而不是多个系统各自建设。

日志与流水设计

作为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架之外，我们还提供一些运维友好的经验总结，我们一起来看一下我们推荐的日志与流水实现，先来看日志，平台默认回会提供的日志主要有三种，系统日志，引擎日志还有跟踪日志。有了这些日志，在出问题的时候能够帮助我们获取一些关键信息进行问题定位。

要想做到出了问题能够追根溯源，那么右边的这些流水号的设计也是非常重要的，日志与各种流水号配合，能够让我们快速定位问题发生的具体时间地点以及相关信息，能够快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有非常大的帮助，没有这些有用的日志内容，ELK 日志收集套件搭建的再漂亮，收一对垃圾日志也是没用的。通常开源框架只是提供个框架有开发人员自由发挥，而设计一个平台则一定要考虑直接提供统一规范的基础能力。

集中配置管理

微服务分布式环境下，一个系统拆分为很多个微服务，一定要告别投产或运维手工修改配置配置的方式。需要采用集中配置管理的方式来提升运维的效率。

配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。要想做到集中的配置管理，那么需要注意以下几点：

是配置与介质分离，这个就需要通过制定规范的方式来控制。千万别把配置放在 Jar 包里；

是配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架；

就是需要运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。

统一管理门户

微服务架构下，一个大的 EAR、WAR 应用被拆为了多个小的可独立运行的微服务程序，通常这些微服务程序都不再依赖应用服务器，不依赖传统应用服务器的话，应用服务器提供管理控制台也就没得用了，所以微服务的运行时管理需要有统一的管理门户来支撑。我们规划了的统一集中的微服务门户，可以支撑 应用开发、业务处理、应用管理、系统监控等。上图是应用管理页面，就是对我们传统意义上的业务系统进行管理，点击一个业务系统，我们就能够看到系统下有哪些微服务，每个微服务有几个节点实例再运行，可以监控微服务的子节点状态，对微服务进行配置管理和监控。

分布式事务问题

微服务架构的系统下，进程成倍增多，那么也分布式事务一致性的问题也就更加明显。我们这里说的事务一致性，不是传统说的基于数据库实现的技术事务。微服务之间是独立的、调用协议也是无状态的，因此数据库事务方案在一开始就已经不再我们考虑的范围内。我们要解决的是一定时间后的数据达到最终一致状态，准确的说就是采用传统的业务补偿与冲正方式。

推荐的事务一致性方案有三种：

可靠事件模式：即事件的发送和接收保障高可靠性，来实现事务的一致性。

补偿模式：Confirm Cancel ，如果确认失败，则全部逆序取消。

TCC 模式：Try Confirm Cancel ，补偿模式的一种特殊实现 通常转账类交易会采用这种模式。

分布式同步调用问题

微服务架构下，相对于传统部署方式，存在更多的分布式调用，那么“如何在不确定的环境中交付确定的服务”，这句话可以简单理解为，我所依赖的服务的可靠性是无法保证的情况下，我如何保证自己能够正常的提供服务，不被我依赖的其他服务拖垮？

我们推荐 SEDA 架构来解决这个问题。

SEDA : staged event-driven architecture 本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。

持续集成与持续交付设计

在运维方面，首先我们要解决的就是持续集成和持续交付，而微服务应用平台的职责范围目前规划是只做持续集成，能够方便的用持续集成环境把程序编译成介质包和部署包。（目前规划持续部署由 DevOps 平台提供相应能力，微服务平台可与 DevOps 平台集成）

这里要厘清一个概念：介质，是源码编译后的产物，与环境无关，多环境下应该是可以共用的，如：jar、dockerfile；配置：则是环境相关的信息。配置 介质 = 部署包。

获取到部署包之后，微服务应用平台的职责就完成了，接下来就是运维人员各显神通来进行上线部署操作。

微服务平台与容器云、DevOps 的关系

就微服务应用平台本身来说，并不依赖 DevOps 和容器云，开发好的部署包可以运行在物理机、虚拟机或者是容器中。

然而当微服务应用平台结合了 DevOps 和容器云之后，我们就会发现，持续集成和交付变成了一个非常简单便捷并且又可靠的过程。

简单几步操作，整套开发、测试、预发或者生产环境就能够搭建完成。整个过程的复杂度都由平台给屏蔽掉了，通过三大基础环境的整合，我们能够使分散的微服务组件更简单方便的进行统一管理和运维交付。

总结展望

我们再来回顾一下，三大基础环境的关系。微服务应用平台负责应用开发、运行以及管理；DevOps 负责项目管理、计划管理、CI、CD 和团队沟通协作等；容器云平台则负责基础设置管理，屏蔽环境的复杂度。

这三大基础环境的建设情况，直接反应出了企业 IT 能力水平。这三大基础环境是技术人员和企业都希望拥有的，是企业赢得竞争、驱动业务创新的基础，是企业加速数字化转型的必由之路。

最后，我们一起看一下普元正在研发的新一代 The Platform 平台。

上图红框中的内容是与我们今天分享的微服务应用平台相关的部分。整个 The Platform 平台是我们站在企业整体架构规划的角度，从多个维度入手，目标是为企业搭建一个持续发展的 IT 生态环境，加速企业的数字化型。

【架构】微服务架构设计

微服务

软件架构是一个包含各种组织的系统组织，这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)

Monolithic架构

Monolithic比较适合小项目，优点是：

开发简单直接，集中式管理, 基本不会重复开发

功能都在本地，没有分布式的管理开销和调用开销。它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断

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

部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长

稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉

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

微服务架构

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

• 一组小的服务
  服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
• 独立部署运行和扩展
  每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
• 独立开发和演化
  技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
• 独立团队和自治
  团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

        我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。

我们为什么采用微服务呢？

"让我们的系统尽可能快地响应变化" - Rebecca Parson

让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话，那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化，在同期出现了诸多轻量级开发方法（诸如 XP、Scrum）；2001年敏捷宣言诞生，之后又出现了精益、看板等新的管理方式。如果说，这些是为了尽快的响应变化，在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之道。

Autonomous
A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated
A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic
A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient
A Microservice is designed for failure; it is fault tolerant and highly available

Responsive
A Microservice responds to requests in a reasonable amount of time

Intelligent
The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented
Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable
Microservices provide API’s for access by developers and administrators

Composable
Applications are composed from multiple Microservices

Automated
The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

服务之间如何通信

 

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个 的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

 

微服务优点

• 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
• 一个团队的新成员能够更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 微服务能够即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方集成。
• 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

微服务架构的缺点

• 微服务架构可能带来过多的操作。
• 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能双倍的努力。
• 分布式系统可能复杂难以管理。
• 因为分布部署跟踪问题难。
• 当服务数量增加，管理复杂性增加。

需要考虑的问题

• 单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
• 单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
• 单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
• 多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
• 微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
• 还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

API为什么很重要

•服务价值的精华体现
•可靠、可用、可读
•只有一次机会

实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其他的请求被转给到一组服务。

相比于提供普适的API，API网关根据不同的客户端开放不同的API。比如，Netflix API网关运行着客户端特定的适配器代码，会向客户端提供最适合其需求的API。

API网关也可以实现安全性，比如验证客户端是否被授权进行某请求。

设计要素

•Version
•RequstID
•Auth&Signature
•RateLimit
•Docs
•ErrorCode&Message

微服务治理

•按需伸缩
–部署与监控运维成本
•独立部署
–机器数量与部署成本
•业务独立
–服务依赖、治理，版本管理、事务处理
•技术多样性
–环境部署成本、约定成本

•运行状态治理
–监控、限流、SLA、LB、日志分析
•服务注册与发现
•部署
–快速、复制、扩容
–单机开发
•调用
–安全、容错、服务降级、调用延时

服务容错

当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为1 -> N扇出. 在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源(线程，队列等)被耗尽，造成所谓的雪崩效应(Cascading Failure)，严重时可致整个网站瘫痪。

服务依赖

服务框架

1. 服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
2. 监控日志，框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
3. REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
4. 配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
5. 限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
6. 管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
7. 统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
8. 安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
9. 文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。

微服务系统底座

一个完整的微服务系统，它的底座最少要包含以下功能：

• 日志和审计，主要是日志的汇总，分类和查询
• 监控和告警，主要是监控每个服务的状态，必要时产生告警
• 消息总线，轻量级的MQ或HTTP
• 注册发现
• 负载均衡
• 部署和升级
• 事件调度机制
• 资源管理，如：底层的虚拟机，物理机和网络管理

以下功能不是最小集的一部分，但也属于底座功能：

• 认证和鉴权
• 微服务统一代码框架，支持多种编程语言
• 统一服务构建和打包
• 统一服务测试
• 微服务CI/CD流水线
• 服务依赖关系管理
• 统一问题跟踪调试框架，俗称调用链
• 灰度发布
• 蓝绿部署

容器（Docker）与微服务

•容器够小
–解决微服务对机器数量的诉求
•容器独立
–解决多语言问题
•开发环境与生产环境相同
–单机开发、提升效率
•容器效率高
–省钱
•代码/image一体化
–可复用管理系统
•容器的横向与纵向扩容
–可复制
–可动态调节CPU与内存

容器(Docker)与微服务

•Image管理
•系统安全管理
•授权管理
•系统成熟度
•社区成熟度

开发方式影响

随着持续交付概念推广以及Docker容器普及，微服务将这两种理念和技术结合起来，形成新的微服务 API 平台的开发模式，提出了容器化微服务的持续交付概念。
下图传统Monolithic的DevOps开发队伍方式：

这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理，而微服务架构引入以后，如下图：

微服务促进了DevOps方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API交互，做到了松耦合隔绝。

• 首先需要考虑构建DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源；
• 其次保持服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化；
• 同时要保持团队和架构对齐。微服务貌似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
• 最后，打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现我们的初衷。

    微服务的实施是有一定的先决条件：基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入如我们般被动的局面。推荐采用基础设施及代码的实践，通过代码来描述计算和网络基础设施的方法，使得图案度i可以快速安全的搭建和处理由新的配置代替的服务器，服务器之间可以拥有更高的一致性，降低了在“我的环境工作，而你的环境不工作”的可能，也是为后续的发布策略和运维提供更好的支撑。

由于Docker引入，不同的微服务可以使用不同的技术架构，比如Node.js Java Ruby Python等等，这些单个的服务都可以独立完成交付生命周期，如下：

微服务案例

Netflix的微服务架构如下，着重全球分发 高可扩展性和可用性：

Twitter的微服务架构，注重高效的可扩展的数据中心：