世界级微服务大老终于总结出：438页微服务治理体系、实践文档

微服务架构

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在"自己的程序"中运行，并通过"轻量级设备与HTTP型API进行沟通"。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

概念

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

折叠编辑本段现状

微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展，理论上是这样。

折叠编辑本段特点

微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。

微服务是利用组织的服务投资组合，然后基于业务领域功能分解它们，在看到服务投资组合之前，它还是一个业务领域。

微服务这一概念出现于2012年，是因软件作者Martin Fowler而流行，他承认这并没有精确地定义出这一架构形式，虽然围绕业务能力、自动化部署、终端智能以及语言和数据的分散控制有一些常见的特性。

折叠编辑本段服务平台

开源工作流平台 "Imixs-Workflow"发布了一款新的微服务架构，作为工作流来管理解决方案。Imixs的微服务( Imixs-Microservice)提供了一个工作流封装成微服务架构。这一服务可以独立于其背后的技术，绑定到任何业务应用中去。这允许业务应用改变业务逻辑的时，不用更改任何代码。这业务目标可以通过工作流模型控制。

Imixs的微服务是基于Imixs的工作流引擎( Imixs-Workflow Engine)的复杂功能构建的，它可以以多种不同的方法来控制业务数据。Imixs的微服务可以发送电子邮件推送消息、日志业务交换，还可以确保所有类型业务数据的安全。

Imixs的工作流模型可以给业务处理模型(Imixs-Workflow Modeller)中的每种状态单独的设计一个ACL。这许可了高度复杂的业务应用程序，并在每个流程实例周围筑起了安全层。

折叠编辑本段工具开发

Seneca是构建微服务框架的工具，然后把它们构建到测试和部署的devops工作流中。构建和部署基于服务的应用程序都很好，但却无法维护，这一点很折磨人。还要在服务周围实现一些 持续交付模型的形式，然后使用它来管理并发布更新--这是一个比编写代码更棘手的问题。

使用微服务构建现代化应用程序是很有意义的，因为它让你既利用了扩展横向扩展架构，也利用纵向扩展架构;还额外得到API的组合，且在整个业务中可重复利用。可能，每一分钟构都在交付新服务，这样你就必须拥有一个敏捷的且响应的应用程序平台，这一平台一直在不断改进中。

目录内容·

第1章服务及服务治理发展简介

第2章微服务治理技术概述

第3章通过服务度量提供治理依据

第4章通过服务管控实现治理闭环

第5章APM 及调用链跟踪

第6章微服务架构体系的深度治理

第7章构建轻量高效的指标采集能力

第8章构建支持高并 发的高效的指标收集及存储能力

第9章指标可视化及度量能力构建

需要这份微服务资料的小伙伴可以多多支持一下文章。

内容·展示：

2.1.1代理模式

代理模式又称服务端发现模式(server-side discovery pattem)，采用Fapade门面架构模式。服务提供方和服务调用方的交互流程，即代理模式的服务框架，如图2.1所示。

3.1线上微服务度量核心指标及分析手段

指标的定义及汇总要尽量保持简单，过于复杂可能会掩盖某种系统性能的变化，也更难以理解。针对线上微服务治理行为，最基础的度量指标共三个:调用量、调用延时和异常。

4.1分布式服务 鲁棒性的架构保障

对线上微服务进行管控的根本目的是提高服务整体的鲁棒性(鲁棒是Robust的音译，也就是健壮和强壮的意思)。微服务架构本质上是分布式架构的一种， 业界针对分布式服务整体鲁棒性保障有些通用的架构设计原则， 包括冗余、弹性伸缩、单点无状态、 不可变基础设施、 故障传导阻断、基础设施及代码等，对微服务架构同样适用。

5.2.2调用链跟踪的整体架构

5.2.2.1一 个例子

图5.4-C描述了一个典型的分布式环境下的网络调用。来自用户交互界面(UD) 的操作请首先调用了一个业务应用(Action), 这个业务应用分别调用了4个分布式服务S1、S2. S3、S4,其中S1又调用了远程服务SS，S5又调用了远程服务S6,井在服务S6中进行了数据库操作。此外，服务S3调用了分布式缓存。这个网络调用最终在服务S4抛出了一个异常。

6.1.1治理目标

3.2.3节中所介绍的服务间的调用链路梳理、调用深度分析、调用闭环检测本质上都是架构治理的一部分。本节我们要在此基础上做更深度的微服务架构下的架构梳理和优化治理，实现如下的治理目标:

1. 分析单个微服务的架构设计的合理性:
2. 梳理整体架构短板，优化架构体系:
3. 控制服务变更的影响范围。

除了以上治理目标，本节还将探索服务分层及拆分的常用架构模式。

如何获取？

需要这份微服务资料的小伙伴可以多多支持一下文章。