microservice | 伪架构师

Istiod——回到单体的理由

Sat, 11 Jan 2020 20:59:19 +0800

原文：Istio as an Example of When Not to Do Microservices

作者：Christian Posta

近五年来，我尽心尽力帮助各种组织踏入云原生之路。要让团队变得现代化并增强基于软件的产品的交付能力，人、过程以及技术决策都很重要。当应用架构的上限已经成为应对变化和加速发展的瓶颈时，微服务方法可能是合适的，但这并不是唯一的方法。

微服务并非应用架构的乌托邦。

过去，我在这方面发表了一些看法，例如我认为很多团队无法将其落地，实现过程中的困难之处，还提出了一些长远来看会对这项工作有益处的技术。甚至还写了一本书来讲述这一主题。

尽管很多组织已经踏上微服务之旅，远离微服务一文仍然可能是个好起点。

如果你已经踏上了微服务旅程

如果发现微服务不灵，就该正视现实。拨乱反正是做出成功产品的正确举措。

尽管出发点是好的，但开始使用微服务之后，开倒车还是有可能的。如果之前的假设或周遭环境已经发生了变化，重回单体架构也是可以理解的。

为微服务通信构建服务网格的 Istio 社区，控制平面的实现将最终从微服务架构转向更为单体的方式。Google API 基础设施的首席工程师和架构师 Louis Ryan，在 2019 年 KubeConNA 上讲述了这一变化的动机，并在设计文档中进行了阐述。从 Istio 1.5 开始（可能会在 2020 年 2 月中旬），我们可能就会看到 istiod 了，这个组件把前作中多个组件集成为单一进程。

Istio 用于解决因为微服务、云原生架构引入的复杂的应用网络问题，所以为什么 Istio 自身却反其道而行之？最直接答案是：

事实证明，微服务的复杂性无法实现其预期的价值或目标。相反，它违背了这些目标。

对于 Istio 项目来说，似乎单体方式能更好的为目标服务。

微服务模式的 Istio

Istio 是一个开源的服务网格产品，其实现和其它同类产品大同小异，由控制平面和数据平面组成。数据平面由反向代理服务器组成，这些反向代理和各个应用实例伴行，并替代应用行使通信职责。控制平面在请求路径之外，用于对数据平面的行为进行管控。

Istio 的控制平面分为几个组成部分，其职责如下：

Pilot：核心的数据平面配置（xDS）服务器。
Galley：配置监听、验证和转发。
Injector：负责数据平面的注册和初始化。
Citadel：证书签发、Secret 生成、CA 集成等。
Telemetry：Mixer 组件之一，负责聚合监控信息到多种后端。
Policy：Mixer 组件之二，在请求路径之中负责实现策略支持。

运维人员通过一组配置指令来借由这些部件为数据平面提供服务并对其进行控制。

微服务的好处

微服务能够降低变更过程中因为耦合产生的冲突，因此能加快组织的调整速度。有了微服务架构的帮助，每个服务都能可以有自己的团队，独立进行运维，有各自的变更频率和生命周期。这使得开发和运维能够轻装上阵，不会因为变更过程中的锁定、同步、协作等问题拖慢部署和变更的进度。

拆分成微服务的另一个原因就是它的用法和扩展方式。例如一个需要大量读写的服务，能从读写分离上受益，这是因为读取过程需要更多内存（缓存），而写入需要更多的存储或者网络资源。拆分之后就可以放心的给读取服务分配大量内存，而写入服务则可以运行在 SSD 或者 EBS/SAN 等设施加持的服务器上。

拆分微服务的另外几个理由：

安全考虑
领域分隔
针对不同语言的优化
安全分级

微服务架构的复杂性是第一号问题。当单体应用拆分为一些互相通信的小玩意之后，架构的复杂性以及对应的基础设施的复杂性都显而易见地提高了。

除非已经清楚的意识到，这是为了获得更多好处，而做出的一种必要的妥协；否则就应该对假设进行评估，并及时做出反应——这就是 Istio 现在的举措。

回头草

首先要清楚，你的服务是谁开发谁运维的。在 Istio 社区，项目里不同的工作组维持着不同的组件。另一方面，下载、安装和运维 Istio 的用户就不那么清楚了。目前看来，都是由单一的工作组（甚至一个人）在操作 Istio 的控制平面。某种程度上，一组微服务构建的 Istio 控制平面更适合被当做一个更大规模的 SaaS 看待，但是目前的情况看来并非如此。

第二个需要注意的就是部署问题。这些微服务能独自部署么？Istio 的回答是：理论上可以，但实际上可能并非如此。当新版本 Istio 发布时，需要更新/部署所有控制平面的组件。

最后一个问题：”Istio 的各个组件，有各自不同的安全考量和伸缩需求吗？“，答案也并不肯定。来自 istiod 的一段陈述：

目前看来，对于多数组件来说并非如此。然而——控制平面的成本由单一的功能（xDS）决定。相对而言，其它所有组件的消耗微不足道，因此分离并无必要。

为了安全起见，所有的控制平面都处于相同的特权级别：

当前的情况下，Mutating Webhook、Envoy Bootstrap 以及 Pilot，这几个组件的特权级别和 Citadel 基本持平，对它们的滥用所引发的损失几乎相同。

Istio 设计文档中的潜台词就是——“复杂性是万恶之源，或者换个说法：停止焦虑，爱上单体”。

istiod 是一个单体应用，它用较低的复杂性提供了和之前版本一致的功能。组成旧版控制平面的服务都还以子模块的方式存在于项目之中，但提供了更好的运维体验。操作者只需关注单一二进制文件的运行和升级了。

Istio 一旦转向单体的控制平面，会大幅降低复杂性，从而：

只需要对一个单独的服务进行部署和升级。
因为无需关注编排服务自身的配置，因此配置复杂度也降低了。
更容易除错。
提高分发、共享和缓存的效率，降低开销。

另外你可以看一下 Istiod 的 Demo 视频。这个视频基于一个早期版本，因此并不完善。

结论

很高兴看到 Istio 社区在持续提高其易用性和可运维性。转向单体应用的 Istio 带来了很多好处。这个过程会对你的项目产生什么启发么？如果有的话，你会采取什么措施么？

为什么微服务适合我们

Tue, 11 Jun 2019 21:59:30 +0800

最近的爆款文《Segment 放弃了微服务》流传很广，让我想到了 2015 年底，Segment 的一篇关于微服务的文章。似乎目前没有中译文，因此翻译出来，便于对照。

原文：Why Microservices Work For Us

作者：Calvin French-Owen

在 Segment，我们全心拥护微服务理念，但个中原因，可能并不是读者所以为的那样。

微服务和单体的争论已经够多了，我不想再次复盘。微服务的拥趸们说，微服务有更好的伸缩能力，是清晰软件工程师团队责任的的最佳方式。然而单体应用的拥护者则认为，微服务的运维太复杂，难于启动。

但是微服务的主流益处和今天我们要讨论的好处不太相关，我们要讨论的是：可观察。

当周二凌晨 3 点钟收到传呼的时候，如果看到特定的工作单元出了问题，而无需在单体应用的每个函数调用中加入追踪，那这个过程就轻松百倍了。

并不是说紧耦合代码中无法实现良好的可观察性——只是极少有案例能够从第一天开始就具备完善的可观察性支持。

可观察性从何而来？稍作思考，就能列出 htop、sysdig、iftop、ps 等运维工具。

但是这些都不是用来监控单一程序的执行情况的：热门执行路径、堆栈尺寸等。过去 20 年中，我们打磨出来的工具都是围绕主机、进程或设备进行的。

在分布式系统中，我们可以在我们的监控指标中加入请求和网络吞吐，但是多数工具还是会尝试聚合到主机或者服务的级别。

单体应用中，以进程为中心的监控工具很难感知到一个程序的耗时情况。在单体应用中，我们最好的调试方式，要么是用 Profiler 运行程序，或者实现自己的计时指标。

还有更头痛的事情，正因为我们没有能够在函数级别完成监控，才成全了火焰图，令其成为流行工具。

所以在 Segment，我们不再尝试往单体应用中塞进大量功能，而是在微服务方向花大力气。我们打赌，容器调度和编排会变得更简单也更强大，而多数指标和监控会持续以主机和服务为中心。

这里做个提醒，微服务仅在容易创建新服务的情况下才奏效。否则我们只是把可观察性问题替换成了交付问题了。

在另外一篇文章中，我们讲了一下我们服务的大体情况，以及我们是如何使用 Terraform 的。如今我们开始把每个服务拆为模块，所以我们可以在预备和生产环境中复用同样的配置了。

这里有个认证服务的例子，使用 Terraform 来进行资源分配：

/**
 * Task definition.
 */

module "task" {
  source = "../task" # sets up an ECS task

  name = "auth"
  port = 5027
  image = "segment/auth
  image_version = "latest"
}

/**
 * Service implementation.
 */

module "service" {
  source = "../service" # sets up our shared service resources

  # Module variables
  task = "${module.task.arn}"
  name = "${module.task.name}"
  port = "${module.task.port}"

  # Input variables
  iam_role = "${var.iam_role}"
  zone_id = "${var.zone_id}"
  elb_subnets = "${var.elb_subnets}"
  elb_security_group = "${var.elb_security_group}"
  cluster = "${var.cluster}"
  desired_count = "${var.desired_count}"
  environment = "${var.environment}"
}

如果感到好奇，可以看看完整的模块定义的例子。

这里有着显而易见的好处（监控指标）和很低的成本（少量的 Terraform 脚本），因此我们就不再需要将不同的功能挤到一个现存服务之中了。

目前为止，这套方法很有用。

Segment 有点不同寻常：并非微服务们协调工作，我们有大量称为 microworker 的单元。基本上这是同样的概念，不过 Worker 不为客户请求提供服务，而是从队列中读取数据，进行处理之后，然后给消息做一个 ACK。

Worker 没有依赖，因此它比服务简单很多。没有耦合，因此不用担心一个 Worker 中的问题会影响到系统中的其它成员。

实际工作中，有很多因素迫使我们做出了 microworker 的决定。其中最大的因素是我们的团队规模以及我们要尝试构建的产品的规模。

微服务经常的宣传就是，当团队规模变大时，太多人在编写同一套代码。这种情况下，以团队为单位分配代码库的权限是个自然的举措。但是我们认为，对小团队来说，微服务也一样有好处。

很多和我交流的人都吃惊于我们团队的规模之小，列几个数字来证明一下：

400 个私有仓库
70 个不同的服务（Worker）
10 个工程师

我们的产品规模和团队规模形成了鲜明的对比。所以如果我接到告警，告警可能是我编写的代码导致的，这段代码我半年前开发出来之后就再没朋友。

如此情况下，小型的、定义清晰的服务就很有吸引力了。

下面是一个典型场景：因为队列深度导致的告警。

我们可以在队列的监控中检查一下是否是这个原因。

我们可以清楚的知道是哪个 Worker 出了问题（因为每个 Worker 都会订阅单独的队列），也知道去哪里看日志。每个服务日志都有自己的标签，所以我们无需担忧同一应用中不同请求生成不相关的日志造成的干扰。

我们可以在 Datadog 的独立的 Dashboard 上查看这个 Worker 的 CPU、内存，以及 ELB 报告的延迟。一旦我们识别了问题，只要阅读 50-100 行文件就可以获知问题的确切位置（例如内存泄漏）。

在单体应用中，我们也可以为每个端点加入特定的监控。然而如果每个端点都运行在各自的进程中，我们完全可以自由的进行修改，无需担心影响其它部分。

还没有提到的是，微服务让我们有了隔离 CPU、内存和延时（如果是 ELB 代理的服务）的能力。同样是查找一处内存泄漏，在有上百个端点的单体应用的代码中查找，和在一个 Worker 的百多行代码中进行查找，其难度是不可同日而语的。

我理解，这种方式不会适用于所有场合。为了在创建新服务时能够获得所有支持，需要很大的投入。这种投入会受到团队、工作负载以及产品形态等多种因素的影响，可能不那么理想。

但是对任何产品来说，一旦其运行过程存在复杂的运维和负载，我会选择微服务架构。这种架构让基础设施有弹性、可伸缩，并易于监控，无需牺牲开发人员的生产力。

Segment 微服务反水案的一点思考

Sun, 09 Jun 2019 23:58:26 +0800

2015 年底，Segment 博客刊登了一篇文章，Why Microservices Work For Us（下文简称为《Work》），三年多，又来了一篇更具话题性的新作：Goodbye Microservices: From 100s of problem children to 1 superstar（下文简称为《Bye》），两相比较，感觉还是有一定的代表性的，这里做一点整理和记录。

微服务的动机

《Work》中提到，主要是因为原有架构中，故障处理不力，需要有更快的诊断和处理方法，这里提到了两个途径：

问题的快速定位：借助更细致方便的监控指标，为突发事件提供明确指导。
问题的快速解决：在定位问题之后，能够更好的从源码中获得支持并解决问题。

要针对某个功能加入监控指标，在原有单体架构中可能会造成不必要的影响，范围不易控制；而源码方面，越小的服务，通常也代表着相对易读的代码；这两个主要需求都指向了同样的解决方案：微服务。

微服务带来的好处

将原有单体应用拆分为微服务之后，不但解决了监控和排错的问题，还带来了一些额外的好处：

隔离的消息队列，不同订阅互不干涉
隔离系统资源，如 CPU 和内存。
隔离网络，如 ELB。

这里只是原文中提到的好处，更多的照本宣科内容这里就不赘述了。

改造的隐忧

《Work》一文中提到了两次，新建微服务应该如何如何。作者似乎认为，微服务有必要更快的创建起来。但按照我的理解，微服务仅是通过进程隔离的强制手段使得模块之间的边界更加清晰，事实上，因为缺乏单体应用强大的上下文支持，同一系统内的不同微服务，往往会因为上下文问题，导致更加复杂的开发过程。

《Bye》一文中补充的拆分过程

单代码库阶段

因为缺乏有效的时间说明，这一操作让人很迷惑，不知道是不是在《Work》发表的时候，各个服务还是在共用同一套代码。也在共用同一套测试方案。《Bye》中提到，一个失败的提交会导致整体测试失败，因此我们大致可以说，这一阶段里，CI/CD 过程也没能完成分割，个人认为，这种情况不太应该算作微服务。
多代码库阶段

为微服务独立创建各自的代码库，并享用各自的测试组件。
共享库阶段

我认为这一阶段呼应了前面的隐忧，在微服务落地之处，为了更快的建立微服务，开始出现了跨服务的共享代码库。

败局的开始

《Bye》的共享代码库一节，罗列了不少遇到的问题：

共享库版本出现碎片：因为工程需要，并不敢冒险同时更新的多个服务的共享代码，造成部分服务的共享代码滞后。
伸缩能力：微服务架构经常鼓吹的能力，在这里似乎被狠狠抽了一巴掌。

个人的一点分析

我眼中的微服务，务虚的角度上来说，有两个关键字：妥协，怀疑。

这里所说的妥协指的是，我们的系统是存活于一个非“理想状态”中的，不管是“拥抱变化”，还是“面向故障”，都是对不完美世界的具体应对方式。

而怀疑的设计态度，最简单的证据就是对隔离的强调，系统资源、数据的隔离都如此强调，我想，代码的隔离是不言自明的。

反观 Segement 的重构之路，（可能）在宣称微服务的时候，各个服务还躺在同一个仓库里，还在共享同样的测试过程。

在进行代码分离之后，又出现了两个不太容易理解的纰漏：

暧昧的代码：前面提到，怀疑是微服务的基本态度，从《Bye》文中可以看到，他们在几十个服务之间共享了需要进行频繁重构的代码，抛开微服务和单体之争不谈，这个行为实在是无法理喻。
暧昧的负载：在拆分之后，按照《Work》的说法，每个微服务都有了独立的队列和监控，由此推论，各个微服务的负载模型应该是比较容易做个描述的，很可惜的，这里称之为一种艺术。

回到单体之后

此处内容给人一种感觉：“今天是个好日子”。给我的感觉是，一些原本应该在微服务阶段完成的工作，甚至是在微服务阶段之前的单体阶段完成的工作，终于完成了——例如改进的测试方案，这能算是半渡而击么？

牢骚

流水账写到这里，有两个深刻的印象就是，这个团队从来没想过这些微服务是彼此独立的，也从来没把每个服务作为一个单独的交付物进行完善。从这个印象出发，回到单体形态，可以说是——得其所哉。

土味微服务

Fri, 10 May 2019 13:06:50 +0800

前段时间有大佬邀请，参加了一个微服务方面的交流，期间大放厥词，回味起来意犹未尽，整理一稿出来，博诸君一哂。

扯一扯定义

单体应用（monolithic application）这个名词，是经常被拿出来和微服务做比较（吊打）的。知己知彼百战不殆，在说微服务之前，似乎蛮有必要了解一下这个老对手的情况。

按照 Google 程序员的常用抄袭手段，我在 Google 搜索 monolithic application，选一点结果摘录如下：

Wikipedia

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Kodelabs

Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.

根据上面的陈述，会发现很难对单体应用做出一个精准的判断，single program、single-tiered 放到真实世界中，除了单服务器、单进程的小网站之外，这种情况似乎很难看到。在面对几十几百台服务器的时候，我想大概没有架构师会有兴趣让几百台服务器都跑同一个 WAR 吧。

对手身份不太明确，那么会不会是个兔死狗烹呢？微服务的定义又是什么样的呢？下面是 Martin Folwer 给出的定义：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

小有多小，轻有多轻，全自动的范围有多大，去中心化到底有怎样的自治，似乎也都让人摸不到头脑。

虽说概念没有一清二楚，然而从上述的定义来看，微服务是对一些既有的观点进行了强调的：

以业务为中心
多技术栈共存
轻量协议互访
去中心化

据此，我对微服务这个风向的理解，是在传统软件的设计开发体系基础之上的一种变化，相对于翻天覆地的变革，我更愿称之为一种改良。

是谁坑了瀑布流程

人人喊打的瀑布流程，在我看来，面对的是一种类似读书时候经常提到的理想状况：

在理想状况中：

需求是清晰而持久的
基础设施都是稳定的
依赖服务都是靠得住的

过往的开发过程在这种理想状况中，是具备非常多的好处的：

单一的技术栈有利于人才招聘、培养以及技术积累。
少量的业务进程对发布、运维都有较小的压力，并且内部调用效率更高。
集中数据的好处更是车载斗量，安全、事务等方面有极大的优势。

然而世界发生了变化，廉价服务器包打天下，IT 人满坑满谷，业务日新月异，新技术层出不穷，用户漫山遍野，这一切因素叠加起来，都让以前重如千钧的需求变得相当轻浮。

结果现在越来越多的开发过程，变成了这样：

所有的环节，都随时面临变化的冲击：

既有需求尚未完成，已经产生变更。
设计开发过程受到新技术新方法的冲击。
测试标准、交付标准的变化。
运行环境升级和故障响应要求。

种种变化归结起来：

硬件和人力都变得廉价，变更频繁并且范围更大。

快速的变化除了产生需求之外，还让黏连在一起的大进程难于适应：

不同业务之间的信任关系会发生变化。
共享数据容易污染。
多小的代码变更，都可能引发大量的测试和上线动作。
特定业务场景无法使用最优技术栈进行实现。
必须同步进行缩放。

除了上述的外部因素之外，开发团队和交付物自身其实也同样的不理想：

牵一发而动全身的共享代码库。
不严格的组件边界，可能导致不同业务互相干扰。

应对思路也顺理成章：

越长的流程越容易被变化击中，换句话说，越短的流程越容易完成。
缩短的流程，决定了交付物体积缩小，但是并行开发的需求大增。
并行开发的过程，要求有多团队协同工作。
多团队的结果就会导致扩展技术栈、去中心化的要求。

更小的交付物，和更便宜的服务器勾搭起来，产生了大量运行小进程的廉价服务器，自然也就催生了“民用”的分布式计算。

如此一来，各种集群、各层协议、各种分布式框架就成了刚需，产生了空前发展。

从“集中力量干大事”，到“各村有各村的高招”，这种变化自然是为了满足客户需要。

没有 Silver Bullshit

按照前面提到的思路，我们：

把进程内的组件拆成独立服务。
独立的服务运行各自的进程。
原有的进程内调用变成了网络调用。
各个服务可能采用不同的技术栈来实现。
每个服务独占存储自己的存储。

大的有点不好，小的就一定好么？各自放飞的微服务，有了各自的实现、发布、伸缩的弹性，是不是就一定好了？

更多的服务器，和相关设施，代表着更多的故障。所以微服务经常强调的是面向故障进行设计。
分离的数据，相对于原有的单一数据库来说，事务保障变得复杂无比。
大量的进程会给运维工作带来很大压力，急需监控和自动化的大力支持。
单一业务的调用序列大幅延长，调试优化难度也一定是大大增加了。
散乱的技术栈，会大幅提高技术管理的难度，降低知识的复用性。
独立的代码库，很明显会降低代码复用的可能性。

由此看来，这种拆分并非只赚不赔的好买卖。是一个需要权衡的事情。不论微服务的数量有多大，个头有多小，作为一个独立的交付物，都还是需要遵循既有的软件开发技能和规律的。那么问题来了——对于给定的系统，到底应该有多少个微服务，每个服务有多大呢？

前文说道，我更愿意称微服务为一种改良，他是一种应对变化的手段，而非特征。在如今的情况下，不管是对新业务实现的设计，还是对既有系统的重构，任何架构师都不会把明明应该拆分的东西硬性的合并到一起。所以这个分离的标准就比较重要了。

拆还是不拆，这是个问题

很明显的，微服务的设计不是一个靠数量取胜的事情，所以重点不是能拆成多少块，而是什么东西需要拆，下面列出我所知的几个影响因素。

组织机构

利益人的识别，在各种软件开发过程中都是很重要的一个环节，在微服务中也是如此，而且尤其重要。当一份交付物存在多个利益人，并且互相之间不存在管辖关系的时候，就表明当前交付物的边界出现了问题，面临着令出多头、需求干扰的风险。

伸缩需求

同一个进程之内的不同业务功能，有时在业务量方面会出现较大的差异，具体要求的进程数量会有较大差别，这样的模块锁定在同一进程之内，势必会造成资源的浪费。

部署频率

这个很容易理解，同一个交付物内不同的组件有着不同的上线频率，会大大的提高上线流程的发生频率，会造成较大的人员浪费。

修改的相关性

如果同一交付物内的不同组件，经常会被同步修改，这可能说明，如果发生拆分，这两个模块应该是”在一起“的。

技术栈

新技术的爆发，让很多不同的场景有了更好的实现方式，如果有业务急需使用新的技术栈来（重新）实现。这种新技术除了新的语言、新的数据库之外，可能还包括容器、Service Mesh、API 网关等新晋 PaaS 能力。毫无疑问，这种业务也同样有拆分的需要。

结论

微服务虽说不是一个全新的东西，但也绝非是简单的新瓶装旧酒。总体说来，我认为这是在尊重现实，适当妥协的基础上，一种应对变化的好办法。

参考

混合微服务模式

Thu, 04 Apr 2019 01:23:56 +0800

原作者：Sonya Koptyev

原标题：Why a Microservices Hybrid Model Is What You Probably Need Instead

在听到别人谈及微服务的时候，你会注意到他们讨论的是一个非此即彼的问题：重构成微服务？还是固守单体形态？这种想法很合情理：微服务是个复杂的话题，把这个复杂性简化成一个二选一问题，就轻松了。

然而微服务实际上并不是一个非黑即白的概念。在应用中部分使用微服务，其它组件仍然保持单体应用的状态，这是一种完全有可能的情况。

这就成了一种混合模式的微服务。本文中我希望能解释一下混合微服务的具体含义，为什么会用到这种模式以及如何构建混合模式的微服务。

混合微服务的概念和来由

简单来说，混合微服务应用意味着应用的一部分是用微服务的方式来进行开发和部署，其它部分则还是单体形式。

可以将其与混合云相类比，混合云中包含了公有云、私有云，可能还有其它的自有基础设施。目前来看，混合云是一种流行的实践方式；实际上，可能很难找到一个完全单一云模式的组织。

如果我们能和混合云共处，那么也应该能够应对混合微服务架构。这种做法能够比较简单的获得微服务在弹性、容量和安全方面的好处，又无需使用微服务架构将传统应用完全重构。

对多数组织来说，将一个单体应用完全重构为微服务的过程中，对开发资源的调动是一个很严峻的问题；采用混合微服务策略是一个较好的方式，对开发团队来说，这种方式让微服务架构触手可及；否则的话，开发团队可能会因为时间、经验等方面的欠缺，无法接受对单体应用的重构工作。

构建混合微服务架构的最佳实践

混合微服务架构的基本概念很容易理解，但是实现起来就颇值得玩味了。首先面临的问题就是，需要对你的应用进行鉴别——哪些部分需要微服务改造，哪些部分需要保持单体形态。这里给出一些提示。

最大化收益的部分优先重构

最醒目也是最重要的事情就是，应用的哪些部分重构为微服务会获得最大收益。

哪些部分需要重构？要解答这个问题很明显根据实际情况来进行判断，但是还是存在一些指导性的微服务改造原则的：

伸缩性：你的应用中，可能有些部分需要比其它部分更多的实例数量。例如一个系统的首次访问可能需要登录，这就可能使得认证模块在某一时间出现峰值，而其它模块则不存在这种波动。这种情况下，将认证模块拆分出来形成独立的微服务，就能让你用更少资源来满足认证的峰值需要。
安全性：应用中哪一部分最多暴露在安全威胁之下？哪一部分最有可能被入侵从而影响到其它部分的安全？这些组件应该优先转换为微服务，这样有利于进行有效的隔离，降低安全风险。
更新：微服务的一个重要优势就是能够在不打扰其它微服务的情况下进行独立更新。有时一个应用中的不同组件会有不同的更新频率。有时候你会在很少更新后端的情况下，频繁的变更接口。这种情况下，可以把前端重构为一个或多个微服务，从而能够更容易的进行这部分的更新工作，让原有的后端继续以单体应用的形式进行。

正视微服务的复杂性

微服务有很多优势，但是也有其固有的缺陷：把系统变得更复杂。这种额外的复杂性，直接提升了开发和运维工作的难度。

正因如此，混合微服务的方式就很有意义了，可以尽可能的降低微服务引入的复杂性。例如哪一部分的 API 调用更少，或者哪一部分可以打包为独立的容器。如果优先对这些组件进行重构，就能够有效的减少 API 调用，降低容器化的难度。

面向未来

和混合云一样，混合微服务策略不是一蹴而就的。这是个持续的过程。可能起初只有一小部分的组件被独立出来成为了微服务，从而形成了混合微服务架构，但是不必止步于此，随着时间的推移和环境的变化，可能会有更多的重构需求。

所以在踏上混合微服务之路的时候，应该设计一个微服务的路线图。就算不具体到时间，至少也应该对你的混合微服务应用有一个基本的演进设想。

结论

我们都希望改善我们的单体应用，但实际情况是，多数情况下我们不会有足够的开发资源把单体应用迅速的重构为微服务架构。与其全盘放弃，不如考虑一下这种混合微服务架构。可以参考上面提出的标准，来决定需要进行微服务改造的模块，需求不够迫切的其它部分，继续以单体应用的模式提供服务。

Medium 的微服务架构

Sat, 10 Nov 2018 12:09:56 +0800

作者：Xiao Ma

原文：Microservice Architecture at Medium

微服务架构的目标是帮助工程团队安全快速地完成高质量的产品交付。良好解耦的服务能够在最小化对其它系统的影响的条件下进行快速迭代。

2012 年构建的 Node.js 单体应用构成了 Medium 的最初技术栈。我们构建了各种卫星服务，但是并没有提出系统化采用微服务架构的策略。2018 年初，随着系统复杂性的提高和团队规模的扩大，我们开始转向了微服务架构，工作中总结出一些如何高效完成这一过程并避免微服务症候群的经验，本文将分享这一经验。

什么是微服务架构

首先我们花费一点时间来思考一下，微服务是什么/不是什么的问题。目前的软件工程有一些滥用和混乱的趋势，微服务就是其中一个。Medium 认为微服务是：

微服务架构中，多个松耦合的服务协同工作，每个服务聚焦于一个单一的目的，而这一目的相关的数据和行为则在单一服务内高度聚合。

这一定义中包含了微服务的三个设计原则：

单一目的：每个服务应该专注于做好一件事。
低耦合：服务之间极少互相了解。对一个服务的变更不应该要求其它服务也进行变更。服务之间的通信金应该发生在公开的服务接口之中。
高内聚：每个服务应该对所有相关的行为和数据进行封装。如果需要构建新的功能，所有的变更只应该落地到一个服务之中。

进行微服务建模的过程中使用应遵循这三条原则。这是释放微服务能量的唯一途径，违反任何一条，都会违反微服务模式的理念。

如果违反了目的单一性原则，每个微服务最终都会负担太多任务，成为多个单体服务。这无法获得微服务应有的好处，并且要付出更多的运维成本。

不遵守松耦合原则的后果是，一个服务的变更会影响到其它服务，所以也就无法快速安全的进行发布——这是微服务的核心优势。紧密耦合还可能造成数据冲突甚至丢失。

而如果缺乏内聚性，就会变成分布式的单体系统——为了完成一个功能修改，必须同时变更和部署一堆服务。分布式的单体系统经常比中心化的单体系统更加糟糕，多个服务甚至多个团队的协调过程造成更高的复杂度和成本消耗。

同时，微服务不是什么，也是个同样重要的问题。

微服务不一定是一个行数较少、或者完成细小任务的服务。显然，这一个误解是来自于微服务这个名字的。微服务架构的目标不是创建尽可能多的服务。符合上述三个原则的服务，可能结构复杂，可能规模庞大，也一样可以称之为微服务。
微服务不一定需要用最新的技术进行构建。虽说微服务架构让团队能够更方面的试水新技术，但这不是主要目标。用同样的技术构建所有新服务完全没有问题，团队同样能从服务解耦中获益。
微服务并不一定需要从头做起。如果已经有了一个架构良好的单体应用，应该避免从头构建所有新服务。可能会有机会对单体服务进行分拆。再一次提醒，上面的三个原则是应当坚守的。

为什么是现在

在 Medium 需要在产品或者工程方面作出重大决策时，经常会提出一个问题：为什么是现在？“为什么”是个很明显需要解决的问题，但这个问题的答案在假设我们有无穷的人力、时间和资源，很明显这是一个危险的假设。把这个问题改为“为什么是现在”，就突然出现了很多的制约——对现有工作的影响、机会成本、并行的开销等。这一问帮助我们更好的确定优先级。

为什么现在要使用微服务架构的原因就是——我们的 Node.js 单体应用在很多方面都成为了瓶颈。

首先最紧急和重要的瓶颈就是它的性能。有一些重度计算和重度 I/O 的任务并不适合 Node.js。我们一直在持续这一单体应用的改进工作，然而并无起色。低下的性能妨碍了产品改进工作——功能的改进可能让这个已经很慢的应用更加缓慢。

第二，一个重要且有点紧急的瓶颈就是单体应用拖慢了应用开发过程。所有的工程师都在单一的应用中构建功能，耦合在一起。因为可能存在的互相影响，我们没法轻松的对系统的某一方面做出变更。整个应用作为一个整体进行部署，所以如果一个不良提交导致了问题，那么这次部署中涉及的所有其它变更不论工作状况有多完美，都会受到拖累。而在微服务架构中，团队可以更快的交付、研究和迭代。正在构建的新功能会从其它复杂系统中解耦出来，让开发团队可以专注于此。所以新的变更能够更快的推向生产环境，从而具备了安全尝试变更的机会。

在我们新的微服务架构中，变更可以在一小时内发布到生产环境上，工程师不必担忧这些变更会对系统其它部分造成多大影响。团队还在探索在开发环境中安全使用生产数据的方法——这可是做了多年的白日梦。随着我们工程师团队的发展壮大，这些因素的重要性也日益提升。

第三，单体应用中，很难针对部分任务作出性能扩展，也很难针对不同类型的任务进行资源隔离。单体应用只能为整个系统进行伸缩，为了某个资源大户进行整体扩展之后，对系统中其它的相对简单任务来说，系统资源就处于超配状态了。为了缓解这一情况，我们将不同类型的请求发送给不同的 Node.js 进程。这种做法在某种程度上来说是有效的，但是伸缩一样受到限制，这还是因为单体应用的紧耦合特性造成的负担。

最后一点，也是同样重要的一点。一个即将浮上水面的问题就是单体应用阻止了对新技术的尝试。微服务架构的一个主要优势就在于每个服务可以使用不同的技术栈进行构建，将不同的技术进行整合。微服务架构让我们可以为特定工作选择最优方案，更重要的是，可以更快更安全的完成任务。

微服务策略

微服务之路并非一帆风顺，一旦误入歧途就会对生产力造成损害。本节中我们会分享七条策略，这些策略在我们进入微服务架构的初期给了我们很大帮助。

构建具备清晰价值的新服务。
单一的持久存储是有害的。
服务的构建和运行应该解耦。
详尽、一致的可观察性。
无需从头构建每个新服务。
故障总会发生，必须正视。
从第一天开始预防微服务综合症。

构建具备清晰价值的新服务

可能有人认为采用新的服务架构意味着产品开发的一个暂停，并且需要重写所有东西。这是一种错误方法。我们决不应该为了构建新服务而构建新服务。每次我们构建新服务或者采纳新技术，都必须有明确的业务价值或工程价值。

我们能交给用户的益处，就是业务价值的体现。相对我们的单体 Node.js 应用而言，新服务应该能够提供更多价值，或者更快的提供价值。工程价值就是让工程团队能够更好更快的工作。

如果一个新服务并不具备清晰的价值，我们就会把它留在单体应用中。十年之后 Medium 仍然有单体的 Nodejs 应用在服役也并不是什么大不了的事情。从一个单体应用开始，实际上让我们能够更有策略的进行微服务建模。

单一的持久存储是有害的

建模微服务的一大部分工作就是对持久化数据存储进行建模。要把微服务整合在一起，共享数据存储看起来是个最方便的做法。事实上这种做法是有害的，我们应该不惜一切代价来避免这种情况。下面解释一下原因。

首先持久化数据存储事关实现细节。在服务之间共享数据存储就相当于将服务实现的细节暴露给整个系统。如果这个服务修改了数据的格式，或者加入缓存层，又或者更换了不同的数据库，那么很多服务都必须跟进。这违反了松耦合原则。

其次，持久化数据存储的过程，例如修改、处理和使用数据的方法，并不是服务行为。如果我们在不同服务之间共享数据存储，就意味着其它服务也要复制服务行为。这样就违反了高内聚原则。特定领域的行为被泄漏到多个服务之中。修改了一个行为，就必须修改所有相关其它服务。

微服务架构中，特定类型的数据只应该由单一的服务负责。所有其它服务要使用这些数据只有两个选择，一是通过 API 向负责的服务发出请求；二是持有一个只读的非权威拷贝。

这听起来可能有点抽象，下面提供一个具体的例子。假设我们正构建一个新的推荐服务，这一服务需要一些来自发帖数据表中的数据，这些数据目前保存在 AWS DynamoDB 中。我们可以用两种方式把发帖数据提供给新的推荐服务。

在单体存储模型中，推荐服务能够直接访问单体应用的持久化数据。这办法不太好：

缓存是个麻烦。如果推荐服务共享单体应用的缓存，我们就必须在推荐服务中复制缓存的实现细节；如果推荐服务使用自己的缓存，又无法在单体应用更新发帖数据时进行缓存失效。
如果单体应用决定用 RDS 替代 DynamoDB 进行发帖数据的存储，我们就必须重新在推荐服务中实现一次，当然所有其它共享这一数据的服务都要重来一次。
单体应用中处理发帖数据的逻辑比较复杂，例如如何决定一篇帖子是否可以显示给特定用户。我们必须在推荐服务中重新实现这些逻辑。一旦单体应用修改或者添加了新的逻辑，我们也必须在所有相关服务中重新实现。
不管推荐服务的访问模型如何，它也只能使用 DynamoDB。

在解耦存储模型中，推荐服务和其它新服务都没有直接访问发帖数据的能力。发帖数据的实现细节只存在于单一的服务中，有不同的方式可以实现这一目标。

理想情况下，应该又一个发帖服务作为发帖数据的所有者，其它服务职能通过这一服务的 API 来访问发帖数据。然而为所有的核心数据模型构建新服务可能需要高昂的成本。

在无法采用最佳方案的情况下，还有有两种行之有效的替代方案。视乎不同的数据访问模式，这可能是更实际的方法。选项 B 中，单体应用在相关帖子的数据更新时会通知推荐服务。通常这种操作的时效性要求不高，可以交给队列系统来完成。选项 C 中用 ETL 管道为推荐服务生成了一个帖子数据的只读拷贝，还加入了一些其它潜在可能对推荐服务有用的数据。两种方案里，推荐服务都完全控制了数据，所以它也就具备了正确处理缓存的能力、以及选择合适数据库的自由。

服务的构建和运行应该解耦

如果说服务构建困难重重的话，服务运行更是难上加难。如果服务的构建和运行耦合在一起的话，会拖慢工程团队，团队必须进行重复实现运行机制。我们希望每个服务能够专注于自身工作，无需担忧运行服务的复杂性，其中包括网络、通信协议、部署、监控等。服务管理应该完全从每个独立服务的实现中解耦出来。

服务构建和运行的解耦策略，应该是独立的，并且不依赖于特定的服务实现技术，这样应用工程师能够完全投入到各自服务的业务实现之中。

感谢近年来出现的容器化、容器编排、服务网格、APM 等进步技术，服务运行的解耦比过去任何时候都更加容易实现。

网络：网络（例如服务发现、路由、负载均衡、流量路由等）是服务运行的一个重要因素。传统的方式是为每个平台或者语言都提供库。这是有效的方法，但是不够理想，服务还是需要进行大量工作来完成这些库的集成和管理。有时候应用还要单独实现一些逻辑。现代的解决方案就是在服务网格中运行服务，Medium 使用了 Istio 和 Envoy 的 Sidecar 方案。构建服务的工程师完全不需要担心网络问题了。

通讯协议：不管用什么语言或者技术栈来构建微服务，选择一个成熟、高效、典型、跨平台并无需大量开发投入的 RPC 方案都是至关重要的。支持向后兼容的 RPC 方案让部署更加安全。Medium 选择了 gRPC。

一个常见的替代方案就是通过 HTTP 实现的 REST+JSON，这个方案在服务通讯领域流行已久。然而虽然这一方案对浏览器和服务器之间的通信很有效，但是对于服务间通信却有些不足，尤其是在发生大量请求的情况下。如果没有自动生成的 Stub 和模板代码，就只能手工实现服务端和客户端代码了。可靠的 RPC 实现不只是封装一个网络客户端。另外虽然 REST 很完备，但是有些细节并不能获得所有人的一致认同。例如一次调用，到底是 REST 还是 RPC？一条消息到底是一个资源还是一个操作？等等。

部署：有稳定的方式来构建、测试、打包、部署和管理服务是非常重要的。Medium 的微服务都运行在容器中。目前我们的系统是 AWS ECS 和 Kubernetes 的混合架构，正在向全 Kubernetes 迁移。

我们构建了我们自己的系统，称为 BBFD，用来完成构建、测试、打包和部署服务。在保证对不同服务的一视同仁和让各个服务可以使用各自的技术栈的弹性之间取得了一个平衡。每个服务只要提供一些基础信息，例如监听端口、用用构建、测试和运行服务的命令等。BBFD 会完成其它工作。

详尽、一致的可观察性

可观察性中包含了过程、方法和工具，让我们能够了解系统的工作状况，并在故障期间对问题进行鉴别。日志、性能跟踪、指标、Dashboard、告警都是可观察性的组成部分，它是能够左右微服务架构成败的关键因素。

我们从单体服务向多服务构成的分布式系统迁移的过程中，会发生两件事情：

丢失了可观察性——因为它的难度提高了，且更容易被忽视。
不同团队都在重新发明轮子，最终导致可观察性呈现为一种碎片状态，这实际上就降低了可观测性，很难用这些碎片数据来对问题进行关联或鉴别。

从一开始就应该建立良好的持续的可观察性，因此我们的 DevOps 团队提出了一致观察性的策略，并构建工具达成这一目标。每个服务都有详细的 DataDog Dashboard、告警和统一的日志搜索支持。我们还深度使用 LightStep 来进行系统性能方面的分析。

无需从头构建每个新服务。

微服务架构中，每个服务的任务都是专注做好自己的事情。这里对如何服务的构建方式并无要求。如果正在从单体应用向微服务架构进行迁移，一个需要注意的问题就是，如果能够从单体应用中剥出目标服务，那么可能并不一定需要从头进行构建。

针对是否需要从头构建新服务的问题，我们从务实的角度触发，主要考虑了两方面的问题：

Node.js 是否适合新服务的需求。
用新的技术栈重新实现的成本如何。

如果 Node.js 是一个合适的选型，并且已有的实现并无不妥，我们就会从单体应用中抽取相关代码，以此作为基础来构建新服务。这样一来，虽然用的是既有实现，同样能够享受到微服务架构的益处。

我们的 Node.js 单体应用的架构让我们能够比较方便的抽取代码进行新服务的构建。后面我们还会讨论一下如何正确的构建一个单体应用的问题。

故障总会发生，必须正视

分布式环境中可能包含更多的故障机会。关键服务的故障如果不能及时处理，可能演变成一场灾难。我们应该随时思考如何完成故障的检测和处理。

第一也是最重要的，应该意识到所有一切都会在某个点上发生故障。
RPC 调用尤其需要对故障案例进行着重处理。
确保系统故障情况下的可观测性（上面刚有提及）。
新服务上线之前必须针对故障进行测试，故障应对是新服务的 Check List 的一部分。
尽可能构建自动恢复功能。

从第一天开始预防微服务综合症。

微服务不是万金油，在解决一些问题的同时，也产生了被称为微服务综合症的新问题。如果我们不从一开始就考虑这个问题，事情有可能变得很麻烦，处理起来也要付出更多代价。下面列出一些常见症状。

建模粗糙的微服务危害巨大，尤其是在数量较多的情况下。
引入太多不同的语言和技术，会导致运维成本升高，分化工程团队。
服务构建和运行相耦合，会导致复杂度的急剧升高并拖慢工程进度。
忽略数据建模，导致单体数据存储形式的微服务。
缺乏可观测性，致使性能问题和故障难于定位。
面对问题时，团队可能选择创建新服务，而不是解决问题——即使解决问题是一个更好的选择。
缺乏整体视图的松耦合服务群本身就是一个问题。

是否不该构建单体服务

受益于近期的技术革新，使用微服务架构变得容易了很多。这是否意味着我们应该完全杜绝单体服务的构建了？

不是的。虽说新技术给了微服务更好的支持，但是微服务架构始终是更难更复杂的。对于刚起步的小团队，单体应用依旧是一个更好的选项。然而可以尝试对单体应用架构进行更好的设计，从而降低未来转向微服务架构时所需的投入。

从单体架构起步没什么问题，但是要保证系统的模块化，并按照上面的三个要素（单一目标、松耦合、高内聚）进行架构设计，最终构建成为一组技术栈一致、同步部署并且运行在同一个进程内的服务。

我们在 Medium 就在早期为单体应用做出了一些好的架构决策。

我们的单体应用由高度模块化的组件构成，最终成长为包含 Web Server、后端服务和离线时间处理器的庞然大物。离线处理器单独运行，但是试用了同样的代码。这样就能够相对简单的将业务逻辑抽取出来成为新的服务，新服务能够和之前的实现提供同样的（高级）接口。

我们的单体应用在较低层次对数据存储进行了封装。每个数据类型（一个数据库表）都有两层实现：数据层和服务层。

数据层为特定类型的数据提供 CRUD 操作的实现。
服务层处理特定类型数据的高级逻辑，并为系统的其余部分提供共用 API。服务之间不进行数据存储的共享。

数据的实现细节对其它部分的代码是完全隐藏的，这种做法帮助我们更好的进行微服务架构的迁移。创建新服务来处理某种数据相对来说是比较轻松和安全的。

单体应用还帮助我们对微服务进行建模，并让我们可以无需从头做起，而是专注在系统的最重要部分上进行微服务的迁移。

结语

多年以来，我们的单体 Node.js 应用发挥了巨大作用，然而对于大项目的交付和快速迭代的要求，开始力不从心，所以我们开始系统地、策略地转向微服务架构。我们的探索才刚刚开始，但是已经看到了它的好处和潜力——它戏剧性的提高了开发生产力、让我们可以从大处着眼并对产品做出大规模的改进，同时工程团队得到解放，能够安全的测试新的技术。

如何从单体应用中拆分富数据服务

Tue, 04 Sep 2018 15:48:42 +0800

原文：How to extract a data-rich service from a monolith

作者：Praful Todkar

关于作者：Praful Todkar 是 ThoughtWorks 的首席顾问，专门构建大型分布式商业软件系统。软件的构建过程中，他乐于在尽快实现商业价值的目标下，为复杂问题创建简单、优雅的解决方案。

在将单体应用拆分为较小服务的过程中，最难的部分就是单体服务数据库中的数据拆分。要进行这样的拆分，保证数据有一个全程唯一的写拷贝，并且遵循一系列步骤是很有帮助的。拆分步骤从对现有单体应用的逻辑分割开始：将服务行为拆分为一个单独的模块，然后把数据拆分到单独的数据表中。一系列动作之后，这些元素最终成为一个自治的新服务。

从单体应用向较小服务的迁移是目前的主流趋势。投资进行这样的迁移，其动力在于，围绕业务能力构建较小服务，能够提高开发者的生产力。团队一旦成为服务的主人，同时也就成为自身命运的主人，这就意味着可以不受系统中其他服务的限制，自由的对自有服务进行改善和升级。

这个转换过程之中最难的部分，就是从单体应用所持有的数据库中把新服务所属的数据拆分出来。如果从单体应用中拆分出来的逻辑部分仍然连接到同一个数据库，这种拆分无疑是比较简单的。但是这样一来，数据库就成为跨应用共享数据库，整个系统所呈现出的各自独立的分布式形态仅是徒有其表，在数据库层面，这依旧是一个紧耦合系统。真正独立的服务需要有独立的数据库——格式和数据都专属于服务。

本文中要讲述一系列步骤组成的一个解构模式，用来在最小化业务中断的前提下，从单体应用中拆出富数据服务。

服务拆分过程的指导原则

深入探讨之前，我想首先介绍两个对于服务拆分具有重要指导意义的基本原则。这两条原则能把从单体应用到多服务的拆分过程变得更加平滑，也更加安全。

整个迁移过程中，数据保持有单一的写拷贝

在转移过程中，我们应该保证待迁出服务的数据始终有一个单独的写拷贝。如果出现了多个可写拷贝，就会出现写冲突的风险。当多个客户端同时写入同一块数据的时候，写冲突就会出现。写冲突的应对是比较复杂的——需要选择一个处理模式，并进行相应的处理。例如以最后写入为准的话，会给部分客户端带来意料之外的后果，同时还要通知写入失败的客户端进行相应的纠错处理。这样的逻辑无疑是比较复杂的，应该尽量避免。

这里的服务拆分模式会保证在服务拆分过程中的任意时间点上，都保持唯一的可写副本，从而避免写冲突造成的复杂性。

遵循“架构演进原子化”的原则

我的同事 Zhamak Dehghani 提出一个原则，叫架构演进原子化，代表在架构迁移过程中使用一系列原子化步骤。这些步骤完成以后，架构就完成了承诺的升级。如果这些步骤没有完全执行，那么这一架构的状态会比初始状态更加糟糕。例如决定分拆一个服务，结果最后只拆分了逻辑，没能拆分数据，这样收获的是一个数据库层耦合的状态，这一状态依然会导致开发和运行时的紧密耦合。实际上对比开始分拆之前，系统变得更加复杂，开发和除错的难度也随之增加了。

下面讲到的模式中，我们建议完成其中的所有步骤来完成拆分工作。服务分拆过程之中的最大障碍并非来自技术，而是如何让既有的单体应用客户迁移到新的服务之中去。我们将在第五步讨论这一话题。

服务拆分的步骤

现在让我们进入实际的服务拆分模式之中。为了方便讲述和操作，我们会做一个例子，来解释服务拆分的具体过程。

假设有个单体形态的商品信息系统，用来给我们的电商平台提供商品信息。经过一段时间的发展和演进，这一系统的服务范围不仅包含了商品名称、类目名称等核心信息和相关逻辑，同时还包含了商品定价方面的逻辑和数据。商品核心信息和价格信息之间并没有清晰的边界。

另外系统的变动频率来看，价格方面的系统变更频率要远高于核心信息部分。数据访问的模式也是各有千秋。商品的价格信息变动比核心商品属性同样要快得多。这样一来，把价格部分分拆到单体应用之外，形成一个单独的服务就是个非常有吸引力的想法了。

同商品核心信息相比，价格信息更加适合分拆，这是因为在原有应用的依赖体系中，定价功能是一个叶子节点。核心商品信息被很多其他功能所依赖，例如商品库存、市场等很多功能。如果将核心信息功能分拆出来，就意味着同时要触动很多相关系统，这会产生很大的风险。因此应该在功能依赖图中选择一个有业务价值的叶子节点作为开始。

图 1：类目系统中包含了核心信息和价格信息两部分的逻辑和数据。有两个客户端——Web 应用和 iOS app。

代码的初始状态

下面是商品系统的现有代码。很明显的，这些代码不具备真实的复杂度。然而用来演示拆分富数据服务的重构过程，其复杂度还是足够的。下面的内容中会看到每个步骤中代码的变化过程。

这段代码中包含了一个 CatalogService 接口，用于给客户端提供服务。它使用一个 productRepository 类和数据库进行交互，用于数据的获取和存储。Product 是一个（Dumb data class）哑类，包含了商品信息。哑类设计是一种反模式设计，不过这不是本文的重点。Sku、Price 以及 CategoryPriceRange 几个类都是比较边缘的小类。

class CatalogService…

  public Sku searchProduct(String searchString) {
      return productRepository.searchProduct(searchString);
  }

  public Price getPriceFor(Sku sku) {
      Product product = productRepository.queryProduct(sku);
      return calculatePriceFor(product);
  }

  private Price calculatePriceFor(Product product) {
      if(product.isOnSale()) return product.getSalePrice();
      return product.getOriginalPrice();
  }

  public CategoryPriceRange getPriceRangeFor(Category category) {
      List<Product> products = productRepository.findProductsFor(category);
      Price maxPrice = null;
      Price minPrice = null;
      for (Product product : products) {
          if (product.isActive()) {
              Price productPrice = calculatePriceFor(product);
              if (maxPrice == null || productPrice.isGreaterThan(maxPrice)) {
                  maxPrice = productPrice;
              }
              if (minPrice == null || productPrice.isLesserThan(minPrice)) {
                  minPrice = productPrice;
              }
          }
      }
      return new CategoryPriceRange(category, minPrice, maxPrice);
  }

  public void updateIsOnSaleFor(Sku sku) {
      final Product product = productRepository.queryProduct(sku);
      product.setOnSale(true);
      productRepository.save(product);
  }

下面就开始从商品单体应用中抽取 “Product pricing” 服务的第一步。

步骤 1：识别新服务涉及到的逻辑和数据

第一个步骤中，需要对商品应用中的商品定价服务所包含的逻辑和数据进行识别。我们的商品应用中包含了一个 Products 数据表，其中包含了 name、SKU、category_name 以及 is_active 标志（用于表示该商品是否有效或者已经弃用）等核心数据。每个商品都属于一个商品类目，类目就是一组商品。例如“男式衬衫”类目包含了花衬衫和晚礼服衬衫等商品。同时这个应用中还有一些核心的商品逻辑，例如根据名称进行商品搜索等。

Products 数据表还有一些定价相关的字段，例如 original_price、sale_price 以及 is_on_sale 标志（用于标识该商品是否在售）。商品应用中包含了一些定价方面的功能，比如计算商品价格、更新 is_on_sale 标志。另外还有一个纠结的功能，就是获取一个类目的价格区间，它主要属于定价范畴，但是也要涉及一些商品的核心功能。

图 2：绿色部分是商品的核心逻辑和数据，蓝色部分是定价方面的逻辑和数据。

接下来重新贴一下上面的代码，代码没有发生变化，核心部分加入了注释（原文用蓝绿标识，MD 格式限制，只能用注释代替）。

  // 搜索商品
  public Sku searchProduct(String searchString) {
      return productRepository.searchProduct(searchString);
  }

  public Price getPriceFor(Sku sku) {
      Product product = productRepository.queryProduct(sku);
      return calculatePriceFor(product);
  }

  private Price calculatePriceFor(Product product) {
      if(product.isOnSale()) return product.getSalePrice();
      return product.getOriginalPrice();
  }

  public CategoryPriceRange getPriceRangeFor(Category category) {
      // 搜索指定类目中的商品
      List<Product> products = productRepository.findProductsFor(category);
      Price maxPrice = null;
      Price minPrice = null;
      for (Product product : products) {
          // 商品是否可用
          if (product.isActive()) {
              Price productPrice = calculatePriceFor(product);
              if (maxPrice == null || productPrice.isGreaterThan(maxPrice)) {
                  maxPrice = productPrice;
              }
              if (minPrice == null || productPrice.isLesserThan(minPrice)) {
                  minPrice = productPrice;
              }
          }
      }
      return new CategoryPriceRange(category, minPrice, maxPrice);
  }

  public void updateIsOnSaleFor(Sku sku) {
      final Product product = productRepository.queryProduct(sku);
      product.setOnSale(true);
      productRepository.save(product);
  }

步骤 2：在单体应用中对新服务进行逻辑上的拆分

第二三步是关于逻辑拆分的，要在商品应用持续运作的情况下，对商品定价服务的逻辑和数据进行逻辑上的分割。简而言之就是在创建新服务之前，首先在单体应用中，对产品的定价数据和逻辑进行隔离。这样做的好处在于，由于还在同一个代码库中，如果定错了产品定价服务所包含的逻辑或者数据边界，纠正这一错误所需的重构工作，相对于拆分为新服务之后，会比较简单一些。

第二步的一部分，我们要创建两个服务类，用来封装不同对象的逻辑：

商品核心类：CoreProductService
商品定价类：ProductPricingService

这些服务类会和我们的“物理”类一一对应，也就是后面看到的商品定价和商品核心。我们还会创建独立的存储类—— ProductPriceRepository 用来访问产品定价数据，以及 CoreProductRepository 用来访问核心商品数据，这两种数据目前都存储在 Products 数据表中。

这部分工作中，需要时刻注意的关键一点是 ProductPricingService 或者 ProductPriceRepository 不应该访问 Products 表中的商品核心信息，而应该通过 CoreProductService 类来进行所有商品核心信息相关的访问。下文中会看到对 getPriceRangeFor 方法进行重构的例子。

不允许存在商品核心信息和商品定价信息之间的表关联。类似的，数据库中也不该有核心商品信息和商品定价信息之间的硬约束。所有的 JOIN 和约束都应该从数据库层转移到逻辑层。不过知易行难是个普遍规律，数据库的拆分过程中，这一点是个难度和必要性都很高的任务。

不难看出，商品核心和商品定价之间是有一个共享的标识符的——两个系统中，SKU 都能能够作为商品的唯一标识。这种跨系统标识符会用在跨系统的通信过程之中，它的重要性显而易见，因此必须慎重选择。只能够有一个系统独立掌握这一数据。所有其它服务都只能对其进行只读的引用——在这些服务的视角中，标识符是固定不变的。标识符所属的实体，其生命周期的管理者，是最适合作为该标识符的属主的。例如我们的案例中，商品核心信息服务掌控着商品的生命周期，因此 SKU 标识符也应该由这一部分进行管理。

图 3：商品核心信息逻辑和商品定价逻辑的拆分，此时商品定价逻辑仍然连接在同一个商品数据表上。

下面是重构的代码。你会看到新建了 ProductPricingService 用来负责定价相关的逻辑。另外还定义了 productPriceRepository 用来访问 Products 表中的定价相关数据。现在的 Product 数据类被分为了 CoreProduct 和 ProductPrice 两个类，分别用户处理商品核心信息和商品定价信息。

class ProductPricingService…

  public Price getPriceFor(Sku sku) {
      ProductPrice productPrice = productPriceRepository.getPriceFor(sku);
      return calculatePriceFor(productPrice);
  }

  private Price calculatePriceFor(ProductPrice productPrice) {
      if(productPrice.isOnSale()) return productPrice.getSalePrice();
      return productPrice.getOriginalPrice();
  }

获取指定类目的价格范围，这一功能相对复杂。这是因为它需要获取类目中的商品列表，而这一操作是属于商品核心部分的。getPriceRangeFor 方法首先要调用 coreProductService 的 getActiveProductsFor 方法来获取类目中的有效商品列表。前面提到过 is_active 是商品核心的属性，因此将 isActive 检查也放到 coreProductService 之中。

class ProductPricingService…

  public CategoryPriceRange getPriceRangeFor(Category category) {
      // 获取商品列表
      List<CoreProduct> products = coreProductService.getActiveProductsFor(category);

      // 根据商品列表获取价格
      List<ProductPrice> productPrices = productPriceRepository.getProductPricesFor(mapCoreProductToSku(products));

      Price maxPrice = null;
      Price minPrice = null;
      for (ProductPrice productPrice : productPrices) {
              Price currentProductPrice = calculatePriceFor(productPrice);
              if (maxPrice == null || currentProductPrice.isGreaterThan(maxPrice)) {
                  maxPrice = currentProductPrice;
              }
              if (minPrice == null || currentProductPrice.isLesserThan(minPrice)) {
                  minPrice = currentProductPrice;
              }
      }
      return new CategoryPriceRange(category, minPrice, maxPrice);
  }

  private List<Sku> mapCoreProductToSku(List<CoreProduct> coreProducts) {
      return coreProducts.stream().map(p -> p.getSku()).collect(Collectors.toList());
  }

getActiveProductsFor 方法获取指定类目商品列表的代码大致如下：

class CoreProductService…

  public List<CoreProduct> getActiveProductsFor(Category category) {
      // 获取类目下的商品列表
      List<CoreProduct> productsForCategory = coreProductRepository.getProductsFor(category);
      // 只返回 is_active 的商品列表
      return filterActiveProducts(productsForCategory);
  }

  // 根据 is_active 进行过滤
  private List<CoreProduct> filterActiveProducts(List<CoreProduct> products) {
      return products.stream().filter(p -> p.isActive()).collect(Collectors.toList());
  }

在本例中，我们把 isActive 的检查保留在了服务中，但是把它转移到数据库查询之中也是很容易的。实际上将功能拆分为多个服务之后，很容易发现这些将逻辑下放到查询层从而提高运行效率的机会。

updateIsOnSale 功能非常直接，可以进行如下重构：

class ProductPricingService…

  public void updateIsOnSaleFor(Sku sku) {
      final ProductPrice productPrice = productPriceRepository.getPriceFor(sku);
      productPrice.setOnSale(true);
      productPriceRepository.save(productPrice);

searchProduct 方法指向新建的 coreProductRepository，用于商品搜索。

class CoreProductService…

  public Sku searchProduct(String searchString) {
      return coreProductRepository.searchProduct(searchString);
  }

原单体应用的顶层接口是 CatalogService，这里也需要进行重构，对不同的功能调用，要委托给不同的服务——CoreProductService 和 ProductPricingService。这个过程很重要，它保障了现有的客户端和服务端之间的契约。

searchProduct 方法委托给了 CoreProductService：

class CatalogService…

  public Sku searchProduct(String searchString) {
      return coreProductService.searchProduct(searchString);
  }

定价相关的方法则委托给了 productPricingService：

class CatalogService…

  public Price getPriceFor(Sku sku) {
      return productPricingService.getPriceFor(sku);
  }

  public CategoryPriceRange getPriceRangeFor(Category category) {
      return productPricingService.getPriceRangeFor(category);
  }

  public void updateIsOnSaleFor(Sku sku) {
      productPricingService.updateIsOnSaleFor(sku);
  }

步骤 3：为身处单体服务当中的新服务创建数据表

这个步骤中，我们要把定价相关的数据拆分到一个新的数据表中——Productprices。这一步骤的最后，商品定价逻辑应该访问 ProductPrices 数据表，而不再是 Products 表。对任何 Products 数据表中关于商品核心信息的请求，都应该从商品核心逻辑层中获取。这个步骤中，除了 productPricingRepository 类之外，所有其他类，尤其是服务类的代码都不应被触及。

这个步骤中要把一个数据表一分为二，因此很重要的一项工作就是 Products 表到 ProductPrices 表的数据迁移。我的同事 Pramod Sadalage 写了一本关于数据库重构的书，如果希望认真的学习这方面的知识，这本书非常值得一读。要做个快速入门，可以看看 Pramod 和 Martin Fowler 的文章：Evolutionary Database Desgin。

在本步骤最后，可能会觉察到新服务可能会对整体系统造成一些影响，尤其是性能方面。逻辑层中的内存内数据 Join 的性能影响是显而易见的。在我们的例子中，getPriceRangeFor 方法就在商品核心信息和商品定价信息之间进行了一次连接。在业务代码中完成数据连接相对于数据库来说，始终是一种更大开销的操作，这也是数据解耦的代价之一。如果在这一阶段中的性能损失非常严重，那么把数据迁回的话，情况会变得更糟糕，更不要提将服务进行物理拆分之后了。如果性能需求（以及可能存在的受这次重构影响的其他需求）无法满足，那么很可能需要重新思考一下服务边界的问题。至少在目前阶段里，Web 应用和 iOS 还都保持良好，这是因为我们没有修改任何和客户端发生交互的部分。这一步骤的另一个功能，就是进行了一次物美价廉的测试。

图 4：拆分成两块：商品核心的数据和逻辑，商品定价的数据和逻辑。

步骤 4：创建新的服务，并且访问单体应用的原有数据库

这个步骤中就要开始给商品定价的逻辑建立新的“物理”服务了，新的服务以 ProductPricingService 为基础，但是数据库依旧沿用单体应用所持有的 ProductPrice 数据表。注意到了这一步，ProductPricingService 调用 CoreProductService 就会变为网络调用了，这种变化不仅会对性能造成影响，还需要增加对超时等网络调用特有问题的处理。

这也是一个业务抽象验证的好机会，这里可以看到新的商品定价服务的建模到底针对的是技术方案还是业务需求。例如当业务用户在执行 updateIsOnSale 时，他的真正需要是在系统中给特定商品创建一个“促销”。下面的代码就是重构以后的 updateIsOnSaleFor。我们响应业务需求，对功能进行了改进，在参数中加入了促销价格，这在以前是没有的。这还是一个将从前流落到客户端的逻辑重新归纳到服务级别的好机会。在客户端的角度来看，这明显是一个有利的变更。

class ProductPricingService…

  public void createPromotion(Promotion promotion) {
      final ProductPrice productPrice = productPriceRepository.getPriceFor(promotion.getSku());
      productPrice.setOnSale(true);
      productPrice.setSalePrice(promotion.getPrice());
      productPriceRepository.save(productPrice);
  }

当然这些重构并非天马行空任意施为的，其中一个重要限制就是不能修改表结构以及表数据的语义，否则可能会破坏掉单体应用中的已有功能。服务拆分大功告成之后（步骤 9），就可以对自己的数据库以及代码为所欲为了。

你可能想要在进行客户端迁移之前进行这一变更，尤其是在大型组织机构中，要让大量不同的服务消费者在限定时间内进行迁移，这一过程需要消耗大量的时间和金钱。下一步中会详细讨论这一问题。新的定价服务可以安全的部署到生产环境中进行测试——反正没有客户端在使用这一服务。同样这里对客户端没有任何变更，例如本例中的 Web 应用和 iOS App 都没有受到任何影响。

图 5：商品定价服务分拆成了新的“物理”服务，新服务在数据方面要依赖单体应用中的 ProductPrices 表，而功能上则要依赖于单体应用中的核心产品功能。

步骤 5：让客户端使用新的服务

这个步骤里，单体服务的客户端中涉及商品定价的部分就需要转移到新的服务上了。这一阶段的工作有两个依赖项：

新旧结构中有多少接口发生了变更。
在组织视角，有多少客户端团队需要及时进行迁移。

这一步骤启动以后，整体架构可能会处于一个中间状态：新旧服务都有客户端在访问。这种状况实际上是比初始状态更加糟糕的。这就是前面讨论过的原子化的架构演进原则的必要性。在迁移开始之前，要获得组织的确认，所有新功能的相关客户端能够按时完成迁移。在架构处于半完成状态期间，是非常容易受到其他的所谓高优先级问题的干扰的。

好消息是，并非所有客户端都需要同时进行迁移。然而在进行下一步之前，完成所有的客户端改造是必要的。可以设置一些服务级的监控机制来监视定价相关的方法，来识别没有完成相关变更的客户端。

理论上可以在客户端完成改造之前开始一些下一步的工作，尤其是下一步中包含了创建定价数据库的操作，但是为了工作的简化，我还是建议尽量按照顺序完成步骤。

图 6：要使用定价功能的客户端已经迁移到新的定价服务。

步骤 6：为新服务创建数据库

这一步相对简单，从单体应用的数据表中进行镜像，创建新的定价数据库。这一过程中有个很大的诱惑就是：既然代码已经进行了重构，干脆也对定价数据库进行一次重构吧。但是数据结构的变化会提高后面将要进行的数据迁移过程的难度。这还意味着新的新的定价服务同时要支持两套不同的结构。我还是建议让事情简单一点：首先分离定价服务（终结所有本文中提到的步骤），然后单独对定价服务进行重构。定价数据库的隔离一旦完成，对数据库的修改就很容易了，毕竟没有客户端会直接访问数据库。

图 7：独立的定价数据库已经建立。

步骤 7：同步数据到新数据库

这一步需要从单体应用的数据库中把定价表的数据同步给新的定价数据库。如果结构没有发生变化，那么这个同步过程是非常简单明了的。基本上相当于把定价数据库设置为原有数据库的只读副本过程（仅涉及到定价相关的数据表）。这样也能保障新的定价数据库的及时性。

迁移完成后，就可以准备在下个步骤中，让独立的定价服务来访问新的定价数据库了。

图 8：从旧数据库中同步定价数据表给新建的定价数据库。

步骤 8：让新服务使用新数据库

开始之前，必须要保证所有使用定价功能的客户端迁移到新的服务上去。如果没有，就面临着写入冲突的风险，这也是前面强调“唯一写拷贝”原则的理由。所有客户端都迁移到新的服务端之后，就需要将定价服务指向新的数据库了。简单说来就是把数据库连接进行一次切换。

这样做的一个好处就是在出现问题的时候，还有机会轻松的迁移回到原数据库。有一种常见问题就是，新数据库中缺乏一些新服务所必须的数据表或者字段。这是步骤一中的失误所产生的后果。有可能是缺少了一些必要的引用数据，比如货币代码。成功解决这些问题之后，就可以进入下一步了。

图 9：指向定价数据库的定价服务。

步骤 9：从单体应用中删除新服务相关的逻辑和数据

这里就要从原有应用中删除定价功能相关的逻辑和数据库了。很多团队会在数据库中留着旧数据，仅仅是因为担心“万一有用呢？”。进行一次全库备份可能有助于缓解这种恐惧。

现在 CatalogService 的所有功能都委托给了对 CoreProductService 服务的调用，顺理成章地，我们就可以移除这一中间层，让客户直接调用 CoreProductService 服务了。

图 10：商品核心只有商品核心的相关逻辑和数据；商品定价服务持有定价的逻辑和数据，二者仅在逻辑层面进行交互。

总结

大功告成！我们成功的把一个富数据的服务从单体应用中解放了出来。

第一次进行这项工作时，会有很多痛苦，也会受到很多教训，这都会让你的下一次拆分更加顺利。初次拆分过程中，不管面对多大诱惑，都最好不要尝试合并这些步骤。一次只进行一步，让整个工作流程更少悬念，更多的安全感和可预测性。在成功掌握这一模式之后，就可以根据自身所学对这些步骤进行优化了。

祝你好运！

服务网格——模式还是技术？

Thu, 16 Aug 2018 10:27:43 +0800

原文：Service Mesh – A New Pattern, Not A New Technology?

原作者：Marco Palladino

Service Mesh 是什么？从何而来？

近几个月，你会注意到围绕服务网格以及未来软件架构的业内讨论如火如荼。这些讨论围绕着几个供应商，呈现出一种部落战争的态势。这种党争虽然司空见惯，但是其中一些共同话题还是很有意义的——例如企业中 API 应用的快速转型，以及服务网格对流量拓扑的意义。

服务 API 最初用于在组织边界提供访问内部系统的接口，供外部开发人员访问；这种情况并未持续很久，很快，服务 API 就变成将内部系统连接在一起的粘合剂。而微服务架构的发展，带来了一个无法回避的后果：数据中心内的内部通信持续增长。服务网格适时出现，提供了一种面向现有技术的部署框架，可能成为应对东西向流量增长问题的一个解决方案。

作为 Kong 的 CTO，我也很热衷于参加这些对话，我注意到对服务网格的认知有一个普遍误解。为了消除误会，升级对话，首先我想要明确提出：服务网格是一种模式，而非技术。

服务网格是一种模式，而非技术

微服务是模式而非技术，服务网格也是一样。这两种概念的区别貌似很难理解。如果我们从 OOP 的角度来看，模式描述的是接口，不是实现。

服务网格这样的部署模式能够利用 Sidecar 增强东西向的流量管理，能给微服务提供强大支援。既然已经对单体应用进行了解耦，并用微服务构建了新的应用，我们的流量模型中，内部流量就会与日俱增。数据中心内，东西向的流量增长原因是我们将单体应用中的函数调用换成了网络调用，这意味着我们的微服务必须融入网络，互相消费。然而地球人都知道——网络靠不住。

面对日益增长的东西向流量，服务网格通过新的部署架构进行应对。传统的南北向通信中，100 毫秒的延迟虽不够理想，但也在可接受范围之内；但在东西向通信中，这就无法忍受了。这是因为服务间的相互调用会使延迟倍增，跨越多个服务的 API 调用和返回，会造成延迟时间的大幅增加。

为了降低延迟，引入了独立运行的 Sidecar，这种代理服务器会伴随微服务进程一起运行，用来移除多余的网络跳跃。Sidecar 在请求的执行路径上担任数据平面的角色，并且避免了单点失败，从而提供了更好的应用弹性。然而，每个微服务进程都配合一个代理进程，势必会造成资源的损耗，但同时他也降低了资源耗尽的肯能性。

经过细致观察不难发现，服务网格中的很多功能，都已经在多年前的 API 管理产品中实现了。比如可观测、网络故障处理和健康检查等功能都是 API 管理的基本配置。这些特性并不新鲜，但服务网格作为一种新的模式，用新思路来完成了这些功能。

传统 API 管理方案瞠目其后

微服务和容器大潮迫使人们更多的关注轻量级进程，服务网格提供的轻量级进程，同时承担了代理和反向代理的角色，伴随微服务进程一同运行。为什么传统的 API 管理方案不采用这种新的部署方案？这是因为他们生于单体时代。这些早于 Docker 和 Kubernetes 面世的 API 管理系统本身就是单体应用，并不适用于新兴的容器生态圈。传统 API 管理方案往往具有重量级的运行时和低下的性能，这些问题在过去的边缘 API 用例中尚可承受，但是对于微服务体系来说，东西向调用量越多，中间环节的延迟就越大。究其根本，传统 API 管理方案的重量大、难度高以及速度慢的缺点是难以满足微服务世界的要求的。

开发人员了解了这些，传统的 API 管理方案引入了称之为 “microgateway”（微型网关）的技术，用来处理东西向的流量，并且避免重写现存的臃肿的单体网关方案。问题是这些所谓的微型网关虽然自身变轻了，但还是要依赖传统方案伴行，用于提供策略实施等能力。这不仅是留下陈旧组件的问题，还意味着增加了延迟。如此种种，服务网格就令人耳目一新了——对手太旧了。

结语

传统的 API 管理方案在南北向流量管理中耕耘多年，服务网格的功能相对来说并不新鲜。多数网络方面以及观测方面的能力对东西向和南北向的流量都是通用的，服务网格让我们有机会运行轻量快速的 Sidecar 代理来完成这些通用功能，改变的是部署模式，不是底层功能。

传统 API 管理方案的功能是服务网格功能的超级，某种意义上来说，普及了可靠性、服务发现和观测能力。服务网格是一种部署模式，用轻量级的方式获得同样的功能。业界经常混淆——有时还加重了这种混淆——很多服务网格方面的讨论，都混淆了特定部署模板和底层技术的界限。

Service Mesh 安全：用 Istio 应对攻击

Thu, 07 Jun 2018 10:10:21 +0800

原文：Service Mesh Security: Addressing Attack Vectors with Istio

作者： Zach Jory

把单体应用拆分为微服务之后，会得到不少好处，例如稳定性的提高、持续运行时间的增长以及更好的故障隔离等。然而把大应用拆分为小服务的过程中，也会引入一个风险就是——可能的受攻击面积变大了。从前单体应用中通过函数调用完成的通信，现在都要通过网络完成。提高安全性从而避免这个问题带来的安全影响，是微服务之路上必须要着重考虑的问题。

Aspen Mesh 的基础是一个开源软件：Istio，他的关键能力之一就是为微服务提供安全性和策略控制方面的支持。Istio 为 Service Mesh 增加了很多安全特性，但是这并不是说微服务的安全工作就结束了。网络安全策略也是需要着重考虑的问题（推荐阅读：In the land of microservices, the network is the king(maker)），结合网络策略，可以检测和应对针对服务网格基础设施的攻击，从而解决各种安全威胁。

后面的内容将会看看 Istio 所能够解决的问题，其中包含边缘通信的流量控制、网格内通信加密以及 7 层策略控制等。

边缘通信安全

针对不当进入网格的流量，Istio 加入了一个用来进行监控和防范的安全层。Istio 以 Ingress Controller 的形式和 Kubernetes 进行了集成，并完成了 Ingress 的负载均衡任务。用户可以用 Ingress Rule 的方式加入安全控制。可以通过监控来了解进入网格的流量，并通过路由规则来管理非法的边缘通信。

要保证只有认证用户通过，Istio 的 RBAC（基于角色的访问控制）提供了有弹性的、可定制的访问控制，这种能力在网格内提供了 namespace、service 以及服务方法一级的控制能力。RBAC 引擎监控和跟进 RBAC 策略的变更，在运行时根据 RBAC 策略，根据请求的上下文对请求进行鉴权，最后返回鉴权结果。

通信加密

边缘通信的安全是个好的开始，但是如果有恶意份子突破了边缘之后，Istio 还为服务之间的通信提供了双向 TLS 认证能力。网格能够对请求和响应进行自动的加密和解密，开发人员就无需在此投入精力了。这个功能还通过对连接的优先复用，减少了连接过程中的运算消耗。

除了客户端和服务器之间的认证和鉴权能力之外，还让用户能够理解和管理服务间的通信和加密。Istio 把证书和密钥自动分发给服务，代理使用这些输入来给流量进行加密（提供双向 TLS），并周期性的进行证书轮转，从而降低证书暴露造成的威胁。可以利用 TLS 来确认 Istio 中的通信双方的服务实例都是合法的，从而防止中间人攻击。

Istio 使用 Citadel 来进行密钥管理和认证控制，简化了 TLS 过程。他让用户能够保护流量，同时给每个服务提供基于身份的验证和授权功能。

策略控制和执行

Istio 给用户在应用级执行策略的能力。对于服务路由、重试、断路以及安全来说，在这一层进行控制是非常恰当的。Istio 为用户提供了黑白名单功能来来对服务进行准入的控制。

Istio Mixer 可以把扩展集成进系统，用户用标准化的表达式语言来来声明网络以及服务行为方面的约束策略。这样做的好处是，可以用通用 API 在服务边缘来缓存策略的决策结果，如果下游的策略系统出现故障，网络还能保持运行。

Istio 解决了一些微服务特定的关键问题。例如只允许被批准的服务间通信，加密通信防止通信过程中的入侵，执行应用范围内的策略等。当然还有很多其他方式可以实现这些能力，Mesh 的好处在于将这些能力融会贯通，让用户使用一致的稳定的方式来完成这些任务。

Aspen Mesh 中正在做一些新的功能，在 Istio 中为用户提供更好的安全能力。近期我们会在博客上发点东西，所以请关注 Aspen Mesh 博客。

如何在企业中尝试无服务器技术

Thu, 07 Jun 2018 02:06:09 +0800

原文：Serverless 101: How to Get Serverless Started in the Enterprise

作者：Michelle Gienow

起初，世上有了裸机，这很好。

独占的服务器很快、很可靠，也很安全——毕竟是独占。但是平心而论，这时候的配置和扩展非常麻烦。对于敏捷和弹性的渴望，催生了虚拟机，云供应商们适时推出了IaaS（基础设施即服务），云端+自助的模式也就自然而然的随之面世了。IaaS 的沃土中，产生了 Amazon Web Services、编排技术、以及基础设置即代码 (IaC: infrastructure as code)；容器化初露端倪、PaaS（平台即服务）也应运而生。当然了，一切都很好，更好了。只不过，开发者们大声疾呼，他们需要语言无关的服务端点、水平伸缩以及实时的服务计费。

祈祷有时候是有效的，这世界得到了一份大礼：无服务器计算，也被称为 Function as a Service (FaaS)。运行时部分只做执行，不保存数据。换个说法就是，AWS、Google Cloud 或者 Microsoft Azure 负责动态的管理资源的分配和分布。

从前使用的基于预测的预付费服务方式已经不适合无服务器计算，取而代之的是根据实际用量进行的即时计费方案。2018 年开始，我们开始将其视为基础设施。

并非魔法

首先，这个名字很有误导性：无服务器计算不是魔法，并不是由神秘的月光驱动的——服务器还是需要的。

这个说法大行其道的原因是，这一架构隐藏了服务器管理以及容量规划和决策等工作。无服务器计算中所谓的“无服务器”，是针对用户和开发者来说的，对他们来说，再也不用花力气、甚至不用知道基础设施了——服务器已经成为一个抽象概念了。无服务器架构中的代码可以和微服务这样的传统的代码部署一起使用——或者可以完全使用无服务器架构来构建应用，就完全不需要关注服务器的问题了。

无服务器架构的真正价值在于时间效率

Bitnami 的云计算高级总监 Sebastien Goasguen 说：“我认为这是一种最小化的 PaaS，一种类似胶水的软件”。“无服务器架构中的关键动作就是——从云中发生了事件，触发了函数的执行。”，Goasguen 描述了 AWS 中的一个场景：把图片保存到存储设施中，接下来调用一个函数来进行图片的缩放。无服务器系统中会处理把这些代码自动的注入到运行时环境中（服务器或者容器），然后进行公开，让函数可以被外部调用。

不是魔法是什么？

传统云计算和无服务器计算的主要区别来自于客户：没人愿意为自己没使用的资源买单。从前我们需要对容量和资源需求进行预测，然后根据预测来采购基础设施——可能是自有也可能是公有云。我们前面的例子中，就是要在 AWS 启动服务器，令其保持就绪，这样才能随时使用这一服务来完成图片的缩放任务——只有在这时候才真正的调用了这一函数。

无服务器计算服务把你的函数作为输入，执行其中的逻辑，然后返回函数的输出，最后关掉。用户只会收到函数执行期间的消费账单。

随用随付，只为实际消费买单，这是个伟大创新。然而 Goasguen 和其他一些 Cloud Native 专家强调，无服务器技术的真正价值不在于成本效率，而在于时间效率。

好像时光机？

是的有点像。或者更像一个通向未来的 Portal，无服务器技术让客户专注的用各种 AI、机器学习等神奇的新技术构建应用，而不是为了跟随时代步伐，永远的建设和翻新基础设施。

无服务器技术的另外一个时光机的特性就是缩短从代码开发到生产运行的时间。简单到了一句话：“这是代码，拿去运行吧”，几乎没有基础设施方面的拖拖拉拉。

Oracle 的无服务器技术副总裁 Chad Arimura 说：“基本思路，开发人员把编写好的代码推送给无服务器服务提供商，其余的部分交给服务商完成。”，另外他还补充说，常见的依赖内容，例如服务器和存储，也会在无服务器计算的环境中提供无缝支持。

“幕后有专家团队和大量的自动化工具来运维这些系统，从而把开发者从这些问题中解脱出来”，Arimura 接下来说，“无服务器的魔术一般的体验，让这一概念的热度持续上升。“

感受 FaaS 平台的力量

Docker 简化了分布式应用的打包和依赖管理，Kubernetes 让企业能够在生产环境中运行这些应用，但是他们的易用性还是不够。Bitnami 的 Goasguen 说：”Dockerfile、基础设施的细节、Kubernetes 的清单——这些对开发思维的受众来说还是稍显复杂的。“

无服务器计算的核心，就是 FaaS 平台。具体点说就是 AWS Lambda 或者 Google Cloud Function，所做的事情：资源管理、负载均衡以及多线程处理；而开发者只需要为雇主专注完成代码即可。

iguaz.io 是一个致力于优化云端性能的持续数据平台，其创始人和 CTO Yaron Haviv 提出：

无服务器平台接收函数代码（FaaS 中的 “F”），为这些代码提供所有的依赖支持（库、内存、配置等），然后构建一个容器化的应用包（通常是 Docker 格式）。
函数的触发方，可以是其他的平台服务，例如对象存储或者数据库；也可以是一个外部的 HTTP 请求。无服务器平台会把请求转发给一个可用的函数微服务上去。如果没有可用的实例，就部署一个——也就是冷启动。
无服务器平台需要处理好微服务的故障恢复、按需伸缩、日志和监控，并在代码变更后执行滚动更新。开发者除了函数本身，所有其他问题都无需关注。

无服务器架构的不足

无服务器并非银弹，还是有一些不足的。有专家说，云服务商经常会缩减一些使用率不高的环境的资源，他们还会限制用户的资源总量，这样就产生一个矛盾——高性能和高延迟同时出现。另外云服务商的监控、排错和安全都会有自己的思路，可能让用户觉得很古怪。这些问题的根源就是：公有云是不受客户控制的。

Amazon Lambda 跟无服务器计算是同时进步的，提供了一个多数人都可以接受的模型。因为 Lambda 是无服务器技术的开创者，所以他的不足也自然而然的被视作无服务器技术的不足：缓慢的冷启动、低性能、短命的函数以及千篇一律的触发器。目前认为这些限制是所有无服务器平台的通病，然而实际上，这是实现过程的一些选择问题。我们应该注意一些新的无服务器平台，例如 Nuclio，他提供了更丰富的用例。这些平台的限制更少，提供更好的性能，同时能够运行在多种云甚至是私有云上。

”极客们喜欢这个，但是企业还在试水——他们连 Docker/K8S 还没用上呢，就来到无服务器时代了，“，Haviv 说。”和任何新技术一样，我们需要首先争取到早期试用者——他们通常更敏捷、更能承受风险，然后才能接近大众。而要获得早期试用者，需要建立信任、看到证据、解决性能、安全等方面的疑难等等。“

显然无服务器技术正在日新月异的向前发展，肯定无法十全十美。虽然下面的话不一定是什么缺点，但却是能让董事们无法安坐在 Aeron 椅子的一个问题：”数字化转型总在被新技术打断，因此企业必须更加敏捷和并正视风险，“Haviv 指出。

”有趣之处在于，Docker/K8S 的抽象是非常复杂的，而无服务器技术虽然更加新潮，却更加简单、更易接受。“

我的公司是否适合无服务器技术？

暂时不提企业适合无服务器技术是好是坏，我们先来看看领导厂商。

Oracle 的 Arimura 认为：”字面上来说，所有组织和公司，只要需要编写软件的，就都适合使用无服务器技术“，”目前的文化和云原生之间的距离越远，就越难应用无服务器技术“，换句话说，如果一个公司没有使用公有云、也没有在内部试用 Kubernetes 或者 Docker 这样的新技术，那么无服务器可能就不是一个合适的尝试。

”这是一个新架构，需要不同的思维方式。最简单的例子：如果一个单体应用拆分为十个微服务，再分为一百个函数，这些单元都具有自己的发布周期和复杂的依赖关系。这很明显需要成熟稳定的持续构建、交付以及自动化系统的支撑。“，Arimura 说，”敏捷创新是无服务器技术的必要支撑，否则造成的害处可能要多余带来的益处。“

”DevOps 的目标不是 NoOps，这完全是个错误思路，无服务器技术更加需要 DevOps 的支持。“

来自 Bitnami 的 Goasguen 补充，采用无服务器技术（尤其是 AWS Lambda）的大多数公司都是以开发者为中心的，他们在此之前已经在应用 AWS，现在使用无服务器计算把服务连接在一起。所以机会就是，如果现在还没有使用 AWS，那么你不需要无服务器技术，然而你仍然应该保持跟踪，开始评估，识别企业中可能存在的事件源，看看如何使用这些事件构建完整的应用管线。

企业如何试水无服务器技术？

”不要把一个单体应用整体转化为微服务或者函数“，Arimura 建议，”使用公司的最重要项目来学习新架构是不明智的，尤其是在公司的文化还在 DevOps 的尝试阶段。“

从小处入手，例如一点自动化任务，或者一些市场活动以及一些事件驱动的用例等。

New Stack 的无服务器技术系列，将协助你的公司探索无服务器的新领域。

Conduit 0.4.2 发布

Tue, 05 Jun 2018 10:04:16 +0800

Conduit 0.4.2 是生产就绪之路上的重要一步。这个版本为代理服务器的长期运行做出了很多修复和提高，并提供了更多的遥测功能。同时也为未来的双向 TLS 版本打好了基础。

生产就绪
- 代理服务器会丢弃 10 分钟未更新的指标，以防长期运行过程中造成的额外的内存增长。
- 新增了一个约束，限制一个节点能够路由的服务数量，缺省为 100。这样在代理服务器长期运行的时候，可以在容量到达上限的时候，丢弃闲置最久的客户端，从而达到节约资源的目的。
- 代理服务器现在能够正确的处理 HTTP/2 请求的取消。
- 修复连接错误时候的请求处理。
- 正确处理 DNS 的 TTL。
- conduit inject 现在可以处理 statefulset 对象了。
遥测
- 新版本的 conduit stat 现在支持所有的 Kubernetes 资源，能够展示一个命名空间内所有对象的流量统计。
- Conduit Web UI 提供了命名空间概述的展示。
- 修复了 Tap 功能的一个 Bug，这个 Bug 让代理服务器无法同时响应多个 Tap 请求。
- 修复了故障状态下，无法报告某些 TCP 流的问题。
- 加入了首字节响应时间的指标。
内部
- 环境配置加入了对友好的时间格式的支持（例如 10s）。
- 控制面使用 Kubernetes 1.10.2 客户端。
- 更丰富的 Debug 日志，包含了 Socket 和 Stream 的元数据。
- 为 TLS 支持对代理做出大量改进。

非常感谢 @carllhw、@kichristensen 和 @sfroment 做出的贡献。

从 0.4.1 升级

从 0.4.1 升级时，建议首先升级控制面，然后再升级注入。

Istio 0.8 的 Helm Chart 解析

Mon, 04 Jun 2018 09:39:10 +0800

儿童节期间，拖拉了一个多月的 Istio 0.8 正式发布了，这可能是 Istio 1.0 之前的最后一个 LTS 版本，意义重大。

新版本中，原来的 Kubernetes 安装文件 install/kubernetes/istio.yaml，变成了 install/kubernetes/istio-demo.yaml，是的，你没看错，这个 LTS 的安装文件名字叫 demo。查看了一下文档，大概察觉到不靠谱的 Istio 发布组的意图了：这个项目的组件相对比较复杂，原有的一些选项是靠 ConfigMap 以及 istioctl 分别调整的，现在通过重新设计的 Helm Chart，安装选项用 values.yml 或者 helm 命令行的方式来进行集中管理了。下面就由看看 Istio 的 Helm Chart 的安装部署及其结构。

使用 Helm 安装 Istio

安装包内的 Helm 目录中包含了 Istio 的 Chart，官方提供了两种方法：

用 Helm 生成 istio.yaml，然后自行安装。
用 Tiller 直接安装。

很明显，两种方法并没有什么本质区别。例如第一个命令：

helm template install/kubernetes/helm/istio \
    --name istio --namespace  \
    istio-system > $HOME/istio.yaml

这里说的是使用 install/kubernetes/helm/istio 目录中的 Chart 进行渲染，生成的内容保存到 $HOME/istio.yaml 文件之中。而第二个命令

helm template install/kubernetes/helm/istio \
    --name istio --namespace istio-system \
    --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml

只是设置了 Chart 中的一个变量 sidecarInjectorWebhook.enabled 为 False。从而禁止自动注入属性生效。

我们照猫画虎，看看命令二的结果提交到 Kubernetes 中会发生什么事情。

helm template install/kubernetes/helm/istio --name istio \
--namespace istio-system --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml

kubectl create namespace istio-system
kubectl create -f $HOME/istio.yaml

根据不同的网络情况，可能需要几分钟的等待，最后会看到这些 Pod 在运行：

istio-citadel-ff5696f6f-h4rdz
istio-cleanup-old-ca-rp5p6
istio-egressgateway-58d98d898c-5jnpz
istio-ingress-6fb78f687f-wsl5q
istio-ingressgateway-6bc7c7c4bc-hhrh7
istio-mixer-post-install-d2kl5
istio-pilot-6c5c6b586c-dqv2w
istio-policy-5c7fbb4b9f-xmv6f
istio-statsd-prom-bridge-6dbb7dcc7f-27tx7
istio-telemetry-54b5bf4847-9gpr7
prometheus-586d95b8d9-gb846

过去的 istio-ca 现已更名 istio-citadel。
istio-cleanup-old-ca 是一个 job，用于清理过去的 Istio 遗留下来的 CA 部署（包括 sa、deploy 以及 svc 三个对象）。
istio-mixer-post-install 同样也是一个 job，和上面的 Job 一样，简单的调用 kubectl 创建第三方资源，从而避免了之前的 CDR 需要重复创建的尴尬状况。
egressgateway、ingress 以及 ingressgateway，可以看出边缘部分的变动很大，以后会另行发文。
和从前不同，缺省已经打开了监控界面。

Helm Chart 的安装配置

下面的配置项目，都可以使用 helm 的 --set key=value 来设置，可以重复使用，用来设置多个值。

选项	说明	缺省值
global.hub	绝大部分镜像所在的镜像库地址	`docker.io/istionightly`
global.tag	Istio 使用的绝大部分镜像的 Tag	`circleci-nightly`
global.proxy.image	指定 Proxy 的镜像名称	`proxyv2`
global.imagePullPolicy	镜像拉取策略	`IfNotPresent`
global.controlPlaneSecurityEnabled	控制面是否启动 mTLS	`false`
global.mtls.enabled	服务间是否缺省启用 mTLS	`false`
global.mtls.mtlsExcludedServices	禁用 mTLS 的 FQDN 列表	`- kubernetes.default.svc.cluster.local`
global.rbacEnabled	是否创建 RBAC 规则	`true`
global.refreshInterval	Mesh 发现间隔	`10s`
global.arch.amd64	amd64 架构中的调度策略，0：never；1: least preferred；2：no preference；3：most preferred	`2`
global.arch.s390x	amd64 架构中的调度策略，0：never；1: least preferred；2：no preference；3：most preferred	`2`
global.arch.ppc64le	amd64 架构中的调度策略，0：never；1: least preferred；2：no preference；3：most preferred	`2`
galley.enabled	是否安装 Galley 用于进行服务端的配置验证，需要 1.9 版本以上的 Kubernetes	`false`

上面的内容来自官方文档，其实这是不符合实际情况的（Istio 用户的日常）。在 install/kubernetes/helm/istio/values.yaml 中，包含这一发行版本中的所有的缺省值。可以直接修改或者新建 values.yaml，并在 helm 命令行使用 -f my-values.yaml 参数来生成自行定制的 istio.yaml

解读 Istio Helm Chart 中的模块

打开 Istio 的 Chart 之后，发现其中并没有任何组件的内容，只有两个 Configmap 对象的模板。其安装主体再次很非主流的通过依赖 Chart 的方式实现了完全的模块化。因此这个 Chart 的主体，实际上是 requirements.yaml，打开这个文件，会看到规规矩矩的列出很多模块，例如：

  - name: sidecarInjectorWebhook
    version: 0.8.0
    # repository: file://../sidecarInjectorWebhook
    condition: sidecarInjectorWebhook.enabled

这表明在 sidecarInjectorWebhook 取值为 enabled 的时候，就渲染这一模板。因此这里可以看做是模块的启用停用的控制点。这里列出的模块包括：

模块	描述
egressgateway	外发流量网关
galley	在 K8S 服务端验证 Istio 的 CRD 资源的合法性
grafana	Dashboard
ingress	Ingress Controller
ingressgateway	Ingress Gateway
mixer	Mixer
pilot	Pilot
prometheus	Prometheus
security	安全相关内容
servicegraph	调用关系图
sidecarInjectorWebhook	自动注入
tracing	Zipkin Jeager 的跟踪服务

下面逐一做一下简要说明

egressgateway

外发通信的网关。

他的设置保存在 values.yaml 的 egressgateway 一节中（都是保存在同名分支下，后面不再重复）。部署内容包括：

Deployment 和 Service：一个 proxy。
HPA
RBAC 相关内容

可定制项目包括：

服务端口和类型
HPA 实例数量上下限
资源限制

galley

之前的 istio 版本中，只能通过 istioctl 验证 Istio 相关 CRD 的有效性，这个模块提供一个在服务端验证 CRD 的方法，他的部署内容包含：

Deployement 和 Service。
RBAC 相关
用于 CRD 校验的 ValidatingWebhookConfiguration 对象。

校验目标包含 Pilot（例如 destinationpolicies 和 routerules）和 Mixer（例如 memquotas 和 prometheuses）两类 CRD。

grafana

一个带有 Istio 定制 Dashboard 的 Grafana 封装。

实际上将其镜像中的 Dashboard 复制出来就可以在其他 Grafana 实例上运行了。

定制内容的 grafana.ingress.* 中包含 Ingress 的配置，用于外网访问。

ingress

Istio 的 Ingress Controller

具体部署内容和 egresscontroller 基本一致。

ingressgateway

0.8.0 新增功能，为 Ingress 通信提供 Istio rules/destination 等特性。

部署内容和 ingress 类似。

mixer

Mixer 负责的是遥测和前置检查，他的 Chart 相对比较复杂，部署内容包括：

和前面的版本不同，Mixer 的部署分成了两个部分，分别是 Policy 和 Telemetry 两个 Deployment 对象。
Service 也同样分成两个，其中 telemetry service 多了一个 prometheus 端口
crds.yaml 中包含了 mixer 所支持的所有 crd 定义（例如 memquotas 和 prometheuses）。
create-custom-resources-job.yaml 中包含了用于创建 crd 的 Job 对象。

pilot

Pilot 承上启下，负责服务发现和向 Proxy 下发配置。除了常规的 Deployment 和 Service 之外，还包含了 crds.yaml，用于声明 CRD 资源类型（例如 destinationpolicies 和 routerules）。

prometheus

这个组件跟前面的 Grafana 类似，也是一个预定义的镜像。这个模板中的 Configmap 就是 Prometheus 的抓取配置，可以直接用到其他的 Prometheus 实例之中。

security

旧版本中的 Istio-ca

Security 部分的部署内容包括：

RBAC
Job：使用 kubectl 清理旧版本 istio-ca 实例。
Deployment，原 CA。
Service：开放两个端口，分别服务于 http 和 gRPC。

servicegraph

Service Graph 支持，和 Grafana 基本一致。

sidecarInjectorWebhook

这一部分的功能是自动为 K8S 对象注入 Envoy。主要包含：

Deployment 和 Service
RBAC 相关
一个 MutatingWebhookConfiguration 对象，会监听 Pod 的创建事件，用于自动注入。

tracing

Jeager 的跟踪支持，总体情况跟 Prometheus 和 Grafana 等监控组件类似，配置项和暴露服务方面稍有区别：

配置中包含 Jaeger 的环境变量的控制。
开启 jaeger 开关，会启用 Jaeger 的几个服务端口。

来自骷髅岛的 Ingress Controller：Kong

Fri, 11 May 2018 12:26:22 +0800

Kong，是一个在 Nginx 反向代理基础上发展而来的 API 网关产品。我之前一直在推动的 Service Mesh，主要关注的是集群（Mesh）内微服务之间的关系，而 API 网关所管理的则是微服务集群边缘，对外服务的管理。（据我观测，Istio 近期的文档已经出现了 Gateway 等说法，似乎也对这方面的问题颇有兴趣的样子）。

传统的 API：

API Gateway：

5 月 8 日，Kong 发布了 Ingress Controller，对 Kubernetes 和对 Kong 自身来说都是个有意思的事情。

首先，Ingress Controller 本来应该负责集群的对外通信，有些 Ingress Controller，例如 haproxy 和 Traefik 已经初步具备了这方面的能力。其次，Kong 之前使用 API 调用的方式来进行管理，在 Ingress Controller 的上下文中，改用 CRD 方式进行管理，对于我等 YAML 程序员来说，无疑是个大大的利好消息。

Kong 使用插件的方式提供了一些常见功能，这些现在也可以用 CRD 方式进行使用，其中包括日志、限流、认证、鉴权几大类。

Kong 同时提供商业和社区两个版本，目前有部分插件也是商业版独占的。

今天这一篇，就会对 Kong Ingress Controller 从部署到应用的介绍。

安装

官方提供了一个简易的 Kubernetes 环境中的安装文件；另外在 Ingress Controller 出现之前，Kong 也有一个相对更丰富的 Kubernetes 下的安装文档。

全部组件都运行在 kong 命名空间。

数据库

安装过程中会创建一个 Postgres 的 StatefulSet，前面提到，这一版本对 Kubernetes 集群的最低版本要求是 1.8，如果是 1.8 版本，需要将这一个 StatefulSet API 版本改为 apps/v1beta2。另外这一部分需要用 PVC 的形式给数据提供存储空间，所以集群中应该设置缺省 StorageClass。完整的 Kubernetes 安装文档中，还介绍了 Cassandra 的存储方式。

CRD

安装过程中创建了如下的自定义资源：

凭据：用于身份认证。
服务消费者：给不同的 API 用户提供不同的消费者身份，以便实施不同的治理方式。
插件：将过去使用 HTTP API 管理的插件系统，以 CRD 的形式在 Kubernetes 环境下统一管理。
KongIngress：对反向代理行为本身进行定义。

服务

其中提供了两组服务：

kong-ingress-controller：暴露 8001 端口，用于对 Kong 进行管理。这里建议将服务类型改为 ClusterIP，而不是直接暴露于公网。
kong-proxy：Ingress 服务，对其承载的接口调用都从此经过，可以根据集群情况酌情使用 NodePort 或者 ClusterIP -> Ingress 的方式对外提供服务。

提供服务

安装结束后，就可以使用网关来对外提供服务了。

官方提供了一个简单的例子应用，我们当然也可以选择别的应用来试用。为他编写一个 Ingress 资源：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: dummy
  annotations:
    kubernetes.io/ingress.class: nginx # 这里仍然是 nginx
spec:
  rules:
  - host: dummy.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: http-svc
          servicePort: 89

如果没有公网 Loadbalancer 条件，可以使用 /etc/hosts、dnsmasq、或者 curl host 几种方式来模拟。

ingress 资源创建成功之后，就可以使用域名来访问这一服务了。

TLS 加密

作为 Ingress Controller，添加证书提供 https 服务也是基本要求之一。这方面 Kong Ingress Controller 使用的是 tls secret 的方式：

首先获取证书，可以自行签名，或者使用已有证书文件。
kubectl create secret tls rocks --key privkey.pem --cert fullchain.pem：创建一个名为 rocks 的 Secret，其中包含我们的证书和私钥。
在 Ingress 资源定义中加入下列内容，引用刚才创建的 Secret：
```
tls:
- hosts:
- dummy.example.com
secretName: rocks
```

这样就可以使用 https 进行访问了。

试用限流插件

前面提到，Kong Ingress Controller 使用 CRD 方式来实现插件的应用。下面我们创建一个限流插件的 CRD：

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: one-per-second-ten-per-hour
config:
  hour: 10
  limit_by: ip
  second: 1

目前并没有很完善的插件 CRD 规范的文档，因此其中的具体字段需要去该插件的文档页面去查找，例如这里引用的 Ratelimit。在这一个 YAML 中我们会发现，其中并没有表明具体使用的插件以及对应的服务，通过对 controller 管理端口的 /plugins 进行查询，也会看到其中并没有定义活动的插件。

要把它应用到具体服务上，还需要修改我们要控制的 Ingress 资源，在其中加入注解，来引用这一 CRD：

kubernetes.io/ingress.class: nginx
rate-limiting.plugin.konghq.com: one-per-second-ten-per-hour

提交新的 Ingress 之后，再次访问管理端口的 plugins 路径，会得到以下响应：

{
    "total": 1,
    "data": [
        {
            "created_at": 1525966801000,
            "config": {
                "redis_database": 0,
                "policy": "cluster",
                "redis_timeout": 2000,
                "hide_client_headers": false,
                "hour": 20,
                "limit_by": "ip",
                "redis_port": 6379,
                "second": 10,
                "fault_tolerant": true
            },
            "id": "8539eb6f-5467-11e8-a92e-000d3a07d45d",
            "name": "rate-limiting",
            "enabled": true,
            "route_id": "f2961715-11fd-410a-a934-dbd6822e5fac"
        }
    ]
}

可以使用 siege 或者 curl/wrk 等其他工具来访问 API，会发现超过限度之后，服务器返回 429 的状态码：

HTTP/1.1 200     0.20 secs:     727 bytes ==> GET  /
HTTP/1.1 200     0.22 secs:     729 bytes ==> GET  /
HTTP/1.1 429     0.20 secs:      38 bytes ==> GET  /
HTTP/1.1 429     0.21 secs:      38 bytes ==> GET  /
HTTP/1.1 429     0.20 secs:      38 bytes ==> GET  /
HTTP/1.1 200     0.20 secs:     729 bytes ==> GET  /
HTTP/1.1 200     0.20 secs:     727 bytes ==> GET  /
HTTP/1.1 429     0.20 secs:      38 bytes ==> GET  /

证明限流功能已经生效。

试用消费者

前面提到，可以使用消费者这一概念，对微服务的用户身份加以甄别，从而提供不同的管控方式。在前面的基础上，我们希望为部分用户修改一下响应内容。

首先创建一个 KongConsumer 对象：

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: rich
username: boss

接下来，为这个用户创建凭据，凭据是需要认证的，所以还要启用一个插件：key-auth，官方文档中并没有提及这一点：

apiVersion: configuration.konghq.com/v1
kind: KongCredential
metadata:
  name: rich-login
consumerRef: rich # 如果删除这一字段，就代表面向所有消费者。
type: key-auth
config:
  key: 62eb165c070a41d5c1b58d9d3d725ca1

然后，为这个用户创建一个插件配置

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rich-response
consumerRef: rich
config:
  hour: 100
  limit_by: ip
  second: 10

最后，在 Ingress 资源中启用两个插件，分别是 key-auth 和 response-transformer

response-transformer.plugin.konghq.com: boss
key-auth.plugin.konghq.com: auth

重新配置 Ingress 之后，可以使用 curl 进行校验：

curl --header "apikey: aasome_key_data" -s -i https://dummy.example.com
HTTP/1.1 403 Forbidden
Date: Fri, 11 May 2018 04:17:57 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: kong/0.13.1

{"message":"Invalid authentication credentials"}

可以看到上面的认证没能通过。

curl --header "apikey: some_key_data" -s -i https://dummy.example.com | grep boss
boss:  true
    x-consumer-username=boss2

Key Auth 认证插件根据 APIKey 取得了用户名，并且激活了 Response Transformer 插件，在 Header 中加入了我们配置的内容。

Kong 原有的 API 在这里还是可以使用的，例如： 1. curl http://[api-url]/plugins 查询生效插件 2. curl http://[api-url] 返回 JSON 中的 /plugins/available_on_server 列出所有可用插件。 3. curl ttp://[api-url]/consumers 列出所有消费者。

Conduit v0.2.0 发布

Thu, 01 Feb 2018 18:27:52 +0800

原文：Announcing Conduit support for HTTP/1.x and TCP

里程碑版本，这次发布中新增了对 HTTP/1.x 和 TCP 支持，这样就可以为绝大多数运行在 Kubernetes 上的应用提供支持了。

数据面
- Conduit 现在为包括 HTTP/1.x 和 HTTP/2 在内的所有 TCP 流量提供透明代理。
控制台界面
- 强化了 tap 命令的错误处理能力。
- tap 也提供了对 HTTP/1.x 的支持。
Dashboard
- 界面进行了小幅更新。
- 可以在 Dashboard 边栏搜索 Deployment。

预告

Conduit 将会为绝大多数协议提供自动支持，然而使用 WebSockets、HTTP 隧道/代理或者 MySQL、SMTP 等协议，需要一些额外配置，文档（注 1）中会有详细说明。
Conduit 还不支持外部 DNS。这一缺憾将在未来版本提供支持。
目前 Conduit 的遥测管线无法扩展到某些节点，后续版本会解决这个问题。
Conduit 还是 Alpha 阶段，请提交 Issue 或 PR 来支持我们（注 2）！

引用：

https://conduit.io/adding-your-service/#protocol-support
https://github.com/runconduit/conduit/issues/new

Conduit 登场

Wed, 06 Dec 2017 09:46:58 +0800

原文：Introducing Conduit

今天我们要介绍 Conduit，面向 Kubernetes 的新的开源 Service Mesh。

Conduit 横空出世，目标是成为最快、最轻、最简单并且最安全的 Service Mesh。他使用 Rust 构建了快速、安全的数据平面，用 Go 开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。更重要的是，Conduit 将会完全吸收过去 18 个月中，我们在 Linkerd 的生产级 Service Mesh 中积累沉淀的真实经验。

为什么要做一个 Conduit？Linkerd 是世界上最多生产级部署的 Service Mesh。这一产品创造了 “Service Mesh” 这一词汇，在软件基础设施中成功的开辟了新的领域，为遍及全球的企业客户（例如 Salesforce、Paypal、Expedia、AOL 以及 Monzo）承载了数以万亿计的请求。这一段时间里，我们和客户以及用户们甘苦与共——我们一起开会，设计交叉路线图，凌晨三点起床救火。开源的基础设施和现实世界的对撞中，我们学到了弥足珍贵的经验和教训。

这中间有个突出的问题就是，Linkerd 的部署模型太重了。虽然 Linkerd 的各个组件，例如 Finagle、Netty、Scala 以及 JVM，都是被广泛采用千锤百炼的，有了这些组件的帮助，在有足够 CPU 和内存支持的情况下，Linkerd 能够达到非常高的负载能力；然而设计过程中鲜有考虑在有限的资源情况下，基于 sidecar 模式的 Kubernetes 部署方式。所以今年年初，我们自问：有了 18 个月的生产级 Service Mesh 的经验，如果要做出一个功能完备又可以在低资源环境下运行的 Service Mesh，我们会怎么做？

答案就是 Conduit。和 Linkerd 类似，Conduit 是让微服务安全可靠的下一代 Service Mesh。他能透明的管理服务之间的通信，自动提供可测性、可靠性、安全性和弹性的支持。还是跟 Linkerd 相仿，他的数据平面是在应用代码之外运行的轻量级代理，控制平面是一个高可用的控制器。然而和 Linkerd 不同的是，Conduit 的设计更加倾向于 Kubernetes 中的低资源部署。

Conduit 为什么伟大（hhhhh）：

轻量高速：Conduit 代理只需要不到 10 MB 实际内存（RSS），p99 延迟在分毫秒以内。
安全：Rust 的内存使用相当安全，同时还缺省使用了 TLS，Conduit 的安全性与生俱来。
最小化：Conduit 的特性集被设计为尽量的最小化和可编排，便于使用 gRPC 插件进行定制。
易用性：内置有聚合的服务指标，强大的客户端工具（想想看，微服务界的 tcpdump），Conduit 为运维人员提供了新的强大的工具来对付生产环境的微服务。

过去半年中我们一直在努力的构建 Conduit。我们聘请了 Phil、Carl、Sean 以及 Brain 这样的高手；向 Tokio 和 Tower 这样的核心技术投资，让 Conduit 又快又安全。最重要的是，我们决心用 Conduit 解决在 Linkerd 社区遇到的实际问题。

Linkerd 怎么办？

简单说说，Linkerd 是世界上最广泛在生产环境进行使用的 Service Mesh，他会长期存在，我们会持续的进行开发、管理并提供商业支持；我们会保证我们的 Linkerd 用户的幸福感。

Conduit 不是 Linkerd 2.0。Conduit 面向的是非常特定的环境 —— Kubernetes，而不准备像 Linkerd 一样做出众多的集成支持。我们的大量用户在使用 ECS、Consul、Mesos、ZooKeeper、Nomad、Rancher 或者混合的多环境系统，Linkerd 是目前的最好选择，我们会持续投入进行改善。

现在开始！

我们刚刚发布了 Conduit 0.1。来跳坑吧！目前这是个 Alpha 版本，所以理直气壮的仅提供 HTTP/2 的支持（是的，HTTP/1.1 都不支持）。我们希望我们的早期用户能够尽早接触 Conduit，并从中获得反馈。

接下来的几个月中，我们会积极工作，推进 Conduit 的生产化进程，预计来年初面世的 0.2 中，会加入 HTTP/1.1 和 TCP 的支持（路线图）。这一产品的进展和目标会非常公开。最后，我们还会提供 Conduit 的商业支持，如果有兴趣的话可以联系我们。

想要了解更多？可以订阅我们的发布通知邮件列表，加入 Linkerd 的 Slack 频道，或者 Follow @runconduit。

Conduit 是基于 Apache 2.0 协议的开源软件。

istio 三日谈之二路由规则

Fri, 28 Jul 2017 17:35:28 +0800

路由控制是 istio 的最常用功能了，经过前面的准备，我们已经基本可以进行这些内容的尝试了。

注意下面的路由规则都忽略了对来源的过滤，会显得比较呆板或者说没用，但是在加入过滤条件之后，就完全不可同日而语了。具体的过滤规则的写法可以参考官方文档或者 istio 中的 bookinfo 实例。

创建 frontend-v2

为了展示路由分配的能力，我们首先创建一个名为frontend-v2的Deployment，这个deploy跟之前的 v1 共享同一个 PVC，也就是共享同一套页面。利用环境变量来控制输出。

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: frontend-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: frontend
        version: "2"
    spec:
      containers:
      - name: php
        image: 10.211.55.86:5000/php:7.1.7-apache
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: wwwroot
          mountPath: /var/www/html
        env:
        - name: "SERVICE_VERSION"
          value: "2"
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: frontend-v1

同前面的 v1 一样，这个Deployment也需要使用istioctl kube-inject进行注入，最后使用kubectl apply -f 运行。

流量分配

首先创建如下路由规则

default.yaml

type: route-rule
name: frontend-default
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: "2"
    weight: 100

destination：必须是服务的 fqdn
precedence：整数，优先级，越大越先
route：数组
- tag：Pod 的标签选择器。
- weigh: 整数，权重，分配到当前路由的比率。

创建之后，使用istioctl create -f default.yaml，创建这一规则。接下来我们使用kubectl exec -it进入 tool pod 进行测试：

$ curl svc-frontend/index.php

-----------------------------
From: frontend-797054967-r12m5
Version: 1

返回内容表明这一服务调用的是最初的 v1 版本的 frontend。

接下来修改 default.yaml 的version "1"为version "2"，然后用istioctl replace -f default.yaml更新路由规则。再次验证：

$ curl svc-frontend/index.php

-----------------------------
From: frontend-v2-90739004-xpmrn
Version: 2

这里可以看到，这一响应来自于 v2 版本的 Pod，并且返回的版本号也是 2。

然后我们再次修改路由规则，测试一下路由分配：

type: route-rule
name: frontend-default
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: "2"
    weight: 10
  - tags:
      version: "1"
    weight: 90

根据上面的路由规则，对 svc-frontend 这一服务的访问，应该有 10% 流量分给版本 2，其余的 90% 分配给了版本 1。我们在 tool pod 中使用如下脚本测试这一分配：

#!/bin/bash
for i in {1..100}
do
  curl -s svc-frontend/index.php | grep Version
done

执行效果：

$  ./curl.batch.sh  | grep 2 | wc -l
10

可以看到，完全符合之前我们的路由设置。

超时策略

为了保障服务质量，我们有时会要求对某些服务的返回时间进行限制

前面提到，我们生成了一个delay.php，用于进行延时测试，文件内容如下：

<?php
header("Content-type: text/plain");
sleep(4);
echo "\n-----------------------------\n";
echo "\nFrom: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

正常执行time curl -s svc-frontend/delay.php，会返回如下结果：

-----------------------------
From: frontend-797054967-r12m5
Version: 1

real    0m4.025s
user    0m0.005s
sys     0m0.004s

我们在这里加入一个策略，两秒超时：

type: route-rule
name: front-timeout
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpReqTimeout:
    simpleTimeout:
      timeout: 2s

再次测试，则会返回超时的结果：

upstream request timeout
real    0m2.015s
user    0m0.006s
sys     0m0.003s

重试策略

在服务超时的时候，我们可能会希望请求自动重试。

这一测试要求保留前面的超时策略，以便形成失败结果：

策略文件如下：

type: route-rule
name: front-timeout
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpReqRetries:
    simpleRetry:
      attempts: 3
      perTryTimeout: 2s

这里表示每次尝试的超时时间是两秒，重试三次。使用 curl 测试：

$ time curl -s svc-frontend/delay.php
upstream request timeout
real    0m8.136s
user    0m0.005s
sys     0m0.006s

时间为 8 秒，相当于四次超时的时间。

Rewrite

和反向代理的情况类似，有时我们需要对进入服务的 URL 进行重写，下面的路由策略会将 /front 替换为 / 进行访问：

type: route-rule
name: front-timeout
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  match:
    httpHeaders:
      uri:
        prefix: "/front/"
  rewrite:
    uri: "/"
  route:
  - tags:
      version: "1"

注意这里对uri的操作，是使用 rewrite 中的 uri 替换 match 中的 uri，二者的对应关系是强制的。

在 tool 里面进行测试访问：

$ curl http://svc-frontend/front/index.php
-----------------------------

From: frontend-797054967-r12m5
Version: 1

故障注入

微服务测试过程中，能够自动生成一些错误，无疑是个很有帮助的事情。目前 istio 支持两种故障的模拟：时延和中断

时延

下面的规则会为每个对该服务的请求都生成 7 秒的时延：

type: route-rule
name: fdelay
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpFault:
    delay:
      percent: 100
      fixedDelay: 7s

percent: 产生时延的比例
fixedDelay: 时间

使用 curl 验证，可以看到的确多出了 7 秒的处理时间。

$ time curl -s http://svc-frontend/index.php
-----------------------------

From: frontend-797054967-r12m5
Version: 1

real    0m7.028s
user    0m0.007s
sys     0m0.003s

中断

这一功能可以模拟服务中断的情景，下面的 yaml 定义了该服务 100% 会返回 403 错误。

type: route-rule
name: fdelay
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpFault:
    abort:
      percent: 100
      httpStatus: 403

curl 的验证结果如下：

$  curl -v svc-frontend/error.php
* Connected to svc-frontend (10.100.186.68) port 80 (#0)
> GET /error.php HTTP/1.1
> User-Agent: curl/7.38.0
> Host: svc-frontend
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< date: Fri, 28 Jul 2017 01:27:52 GMT
* Server envoy is not blacklisted
< server: envoy
< content-length: 0
<
* Connection #0 to host svc-frontend left intact

istio 三日谈之一，环境准备

Fri, 28 Jul 2017 07:00:12 +0800

笔者尝试在一个准生产环境下，利用 istio 来对运行在 Kubernetes 上的微服务进行管理。

这一篇是第一篇，将一些主要的坑和环境准备工作。

内容较多，因此无法写成手把手教程，希望读者有一定 Kubernetes 的操作基础。

准备镜像

初始运行需要的镜像包括以下几个：

istio/mixer:0.1.6
pilot:0.1.6
proxy_debug:0.1.6
istio-ca:0.1.6

首先要解决的自然还是镜像的存放问题，官方在源码中提供了很方便的工具，用来根据模板生成在 Kubernetes 中运行 istio 的 YAML 文件：

./updateVersion.sh \
	-p 10.211.55.86:5000/istio,0.1.6 \
	-c 10.211.55.86:5000/istio,0.1.6 \
	-x 10.211.55.86:5000/istio,0.1.6

这一脚本在源码的 install 目录下。

Kubernetes 环境

这里我们使用的集群大概情况是：

1.7.1 版本的 Kubernetes
开启了 RBAC
预备使用的命名空间为：default
PVC 自动供给
无互联网连接
具有自己的私库

启动 istio

RBAC 相关

首先，install 目录中提供的 rbac 文件授权范围不足，所以需要手工编辑istio-rbac-beta.yaml，把其中的几个 RoleBinding，改为 ClusterRoleBinding。

kubectl create \
	-f istio-rbac-beta.yaml

另外缺省的 ClusterRole 中缺乏对 Namespace 的权限，新版本已经修正，目前版本仍需添加：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: istio-pilot
rules:
- apiGroups: ["istio.io"]
  resources: ["istioconfigs", "istioconfigs.istio.io"]
  verbs: ["*"]
- apiGroups: ["extensions"]
  resources: ["thirdpartyresources", "thirdpartyresources.extensions", "ingresses", "ingresses/status"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["configmaps", "endpoints", "pods", "services"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["namespaces", "nodes", "secrets"]
  verbs: ["get", "list", "watch"]

启动 istio 组件

kubectl create \
	-f istio.yaml \

创建 PVC

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: frontend-v1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

准备工作负载

这里我们使用官方的 PHP + Apache 镜像作为工作负载来进行下面的测试，例如我们准备好的 YAML 如下：

Deployment：

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: frontend
  labels:
    name: frontend
    version: "1"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: frontend
        version: "1"
    spec:
      containers:
      - name: php
        image: 10.211.55.86:5000/php:7.1.7-apache
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: wwwroot
          mountPath: /var/www/html
        env:
        - name: "SERVICE_VERSION"
          value: "1"      
     	volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: frontend-v1

服务定义：

kind: Service
apiVersion: v1
metadata:
  name: svc-frontend
  labels:
    name: frontend
    version: "1"
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32010  
  selector:
    name: frontend

在 Web 目录中我们随便做了个index.php，用来展示当前所在 Pod 和环境变量中的服务版本号，备用。

Tips：一般这类测试，我都懒得重新做一个 Docker 镜像，一般是另外用一个 Pod 挂载同一个 PVC，直接编辑页面文件，或者使用kubectl cp命令进行拷贝。

index.php

<?php
header("Content-type: text/plain");
echo "From: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

delay.php


<?php
header("Content-type: text/plain");
sleep(4);
echo "\n-----------------------------\n";
echo "\nFrom: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

运行成功后，访问该服务的 nodePort，会看到相应的输出内容。

istio 的注入

首先用kubectl delete -f删除上文的服务和 Deployment。

上面为了测试方便，给 Service 使用了 NodePort 类型，这里我们去掉这一服务的 NodePort，用 ClusterIP 的形式运行：

spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    name: frontend

接下来进行注入操作

istioctl kube-inject -f frontend-v1.yaml > frontend-v1-istio.yaml

观察注入操作会发现，其中多了一个 Sidecar Container（下面的 Image 节内容已经被我修改为本地私库）：

    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    image: 10.211.55.86:5000/istio/proxy_debug:0.1.6
    imagePullPolicy: Always
    name: proxy
    resources: {}
    securityContext:
      runAsUser: 1337

另外还在pod.beta.kubernetes.io/init-containers注解中进行了初始化：

[{
  "args": ["-p", "15001", "-u", "1337"],
  "image": "10.211.55.86:5000/istio/init:0.1",
  "imagePullPolicy": "Always",
  "name": "init",
  "securityContext": {
    "capabilities": {
      "add": ["NET_ADMIN"]
    }
  }
}, {
  "args": ["-c", "sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%t && ulimit -c unlimited"],
  "command": ["/bin/sh"],
  "image": "10.211.55.86:5000/alpine",
  "imagePullPolicy": "Always",
  "name": "enable-core-dump",
  "securityContext": {
    "privileged": true
  }
}]

可以看到上面一共涉及三个镜像：

docker.io/istio/proxy_debug:0.1
docker.io/istio/init:0.1
alpine

经过一番折腾：

原有 YAML
注入，生成新的 YAML
替换新 YAML 中的镜像地址

就把原有的容器应用封装成新的 istio 支持的微服务了。

准备测试素材

另外我们需要准备一个工具服务，用于在 shell 中进行测试：

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: tool
  labels:
    name: tool
    version: "1"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: tool
        version: "1"
    spec:
      containers:
      - name: tool
        image: 10.211.55.86:5000/php:7.1.7-apache
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: wwwroot
          mountPath: /var/www/html
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: frontend-v1
---
kind: Service
apiVersion: v1
metadata:
  name: tool
  labels:
    name: tool
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    name: tool

同样的，这里也需要执行istioctl kube-inject进行注入，运行之后，就得到一个运行于集群内部的 Linux Shell，istio 中的路由策略经常是客户端和服务器协同完成的，因此上客户和服务器的 Deployment 都需要进行注入操作。

Istio，Kubernetes 的微服务支持

Sun, 16 Jul 2017 17:17:08 +0800

参考资料： https://developer.ibm.com/dwblog/2017/istio/ http://blog.kubernetes.io/2017/05/managing-microservices-with-istio-service-mesh.html https://istio.io/docs/

简介

Istio 是一个由 IBM、Google 以及 Lyft 联合推出的开源软件，以无痛方式为运行在 Kubernetes 上的微服务提供流量管理，访问策略管理以及监控等功能。这一软件目前仅在 Kubernetes 上运行，今后可能会扩展到其他平台。本文会结合官方例子，完成安装和基础的监控内容。

架构和组件

总体架构如图所示。

Envoy

一个 C++ 编写的高性能代理服务器，这里做了扩展，在 Istio 中会以 Sidecar 方式跟应用运行在同一 Pod 内，一方面可以接收并执行关于规则、流量拆分等方面的指令，另一方面能够产生各种指标用于监控和跟踪。

Mixer

Mixer 组件，主要进行访问控制以及策略控制，同时也负责从 Envoy 中获取各项指标。

Pilot

Pilot 是用户和 Isito 之间的桥梁，负责接收各种配置，并发送给各个组件。

Istio auth

内置认证和凭证管理，利用 TLS 提供服务之间、用户和服务之间的认证。可以用来将没有加密支持的服务升级为加密版本，并且在网络策略之外，提供服务级别的策略控制，今后还会增加更多的鉴权和审计方面的能力。

功能 & 特性

无需对现有服务进行变更
支持 http 1.1/2、gRPC 以及 TCP 流量的负载均衡和故障转移
可替换的组件
流量监控
可提供身份认证功能
可定制的路由规则
错误处理，例如超时、重试、访问量控制、健康检查和熔断器等。

安装

先决条件

Kubernetes
互联网连接

准备工作

首先去https://github.com/istio/istio/releases下载最新版本（目前为 0.1.6），解压并设置 istioctl 命令的执行路径。下面命令中描述的相对目录就是基于此目录

执行命令kubectl api-versions | grep rbac查看当前集群的 RBAC 设置：

如果返回内容为空则无需理会。
如果返回内容中包含beta，则需要运行kubectl apply -f install/kubernetes/istio-rbac-beta.yaml来进行授权
如果返回内容中只有alpha ，就要kubectl apply -f install/kubernetes/istio-rbac-beta.yaml创建相应的角色和绑定了。

运行

最后，运行kubectl create -f install/kubernetes/istio.yaml创建一系列的 Deployment 以及 Services。

注1：其实上面的内容照做并不一定能成功，反正我的 1.6.6 上面是没能成功，Pilot Pod 中的 API Server 容器会出错，错误信息大概是“system:serviceaccount:default:istio-pilot-service-account” cannot get thirdpartyresources.extensions at the cluster scope.”，也就证明了 beta.yaml 中的 RBAC 设置是不够的，这里我把几个 RoleBinding 都改成为 ClusterRoleBinding，运行就成功了。

注2：istio.yaml 中的 Ingress 服务是 Loadbalancer 类型的，如果测试集群不具备这样的条件，还请自行修改成其他合适内容。

至此，基础的 istio 组件就已经运行完毕了。

运行应用

安装包内包含了一个叫 bookinfo 的小应用，由 Product（入口页）、Detail 和 Review 三部分组成，具体应用 YAML 在安装目录的samples/apps/bookinfo/bookinfo-v1.yaml文件中。打开文件我们会发现这是个很简单的小应用，无非是几个 Deployment 和 Service 的组合。

该应用的微服务相互关系大致如下图所示，这个例子很好的展示了 istio 的一大特性——不拘泥于某种语言。

istio 提供了一个工具叫 istioctl，这个工具的功能之一，就是把普通的应用 YAML 注入为 istio 支持的应用模式，例如：istioctl kube-inject -f bookinfo-v1.yaml > bookinfo-istio-v1.yaml，比较新旧两个文件不难发现，这一工具为每个 Pod 新增了一个名为 proxy 的容器，以此接管流量，给监控和管理打下基础。

接下来我们运行这一应用： - kubectl create -f bookinfo-istio-v1.yaml：运行注入后的应用 - kubectl create -f bookinfo-ingress.yaml：创建 Ingress 资源

监控

istio 内置了对 ServiceGraph、Prometheus 以及 Zipkin 的支持，简单的运行一下kubectl create -f install/kubernetes/addons，就会启用这几个服务。注意这几个服务使用的也都是 Loadbalancer 模式，读者应根据集群情况自行修改。

各个服务启动之后，可以使用负载工具例如 wrk 对 Productpage 页面进行一段时间的访问，来模拟工作情况。

Grafana

Grafana 启动后，我们可以使用服务暴露的地址进行访问，在其中可以看到如下图所示的 Dashboard，展示了我们应用中的几个服务的各种监控数据。

Service Graph

这一个服务提供了两个入口，一个是 /dotvz，以图形的方式供服务关系展示，而/graph则提供了 JSON 格式的文档供结构化使用。例如：

{
    "nodes": {
        "details": {},
        "productpage": {},
        "reviews": {},
        "unknown": {}
    },
    "edges": [
        {
            "source": "productpage",
            "target": "reviews",
            "labels": {
                "qps": "0.030416",
                "version": "v1"
            }
        },
        {
            "source": "unknown",
            "target": "productpage",
            "labels": {
                "qps": "0.030416",
                "version": "v1"
            }
        },
        {
            "source": "productpage",
            "target": "details",
            "labels": {
                "qps": "0.030416",
                "version": "v1"
            }
        }
    ]
}

Zipkin

Istio 提供了开箱即用的 Zipkin 跟踪支持，打开页面之后，我们会看到 Zipkin 的查找页面，并无特殊内容，就不展开细谈了。

文中介绍内容只是很粗浅的入门操作，后续会进一步跟进、挖掘和学习这一系统的其他强大功能。

微服务

Wed, 02 Mar 2016 05:41:53 +0800

原文：Microservices

翻到 ²⁄₃ 的时候看到一篇疑似译文，不过并未注明原作和出处，恩。反正我这是学习笔记。

“微服务”——另一个软件架构的流行词。本来我们应该对这类东西扔去一个蔑视的眼神，不过这个名词所描述的软件系统越来越多。过去几年中我们看到很多这种风格的项目，这甚至成为构建企业应用的缺省方式。然而可惜的是，微服务是什么？如何实现微服务？这两个问题却没有明确的解答。

简单来说，微服务架构是一种开发应用的方法，应用由一系列的小服务构成，每个小服务都拥有各自的进程，并提供轻量级的通讯机制（一般是 HTTP 资源 API）。这些服务围绕业务能力进行构建，并且通过全自动方式进行部署。这些服务可能用不同语言、使用不同数据存储来进行实现，最大限度的降低对中心化管理中心的需求。

微服务这个词最早是在 2011 年 5 月威尼斯一个软件架构会议上讨论时，用于描述与会人员当时所探索的通用架构模式。在 2012 年 5 月，同一组人确定了这个最合理的命名。James 在 2012 年 3 月的举行于 Krakow 的 33rd Degree 会议上，以 [Microservices - Java, the Unix Way] 为题，以案例研究的形式阐述了其中的部分理念；几乎同时，Fred George 发表了题为 MicroService Architecture的演讲。Netflix 的 Adrian Cockcroft 称这种方式为 “细纹理 SOA”，他和文中提到的其他人（Joe Walnes, Dan North, Evan Botcher and Graham Tackley），是这一架构的先驱者。

在解释微服务之前，先比较一下 monolithic（单一庞大的，整块巨石构成的）模式：以单个单元构建而成的引用。企业应用通常由三个部分组成：一个客户端的用户界面（包含 HTML 页面以及运行在客户浏览器中的 JavaScript）、一个数据库（通常是一个关系型数据库管理系统，包含很多数据表）以及一个服务端应用。服务端会处理 HTTP 请求，执行业务逻辑，对数据库中的数据进行读写，选择和处理 HTML 视图，并发送给浏览器。这一个服务端应用就是一个单一逻辑的可执行应用，所有对系统的变更都需要构建和发布这一应用的新版本。

巨石这个称呼似乎不错。

monolith 这个词在 Unix 社区用了一段时间了。出自 The Art of Unix Programming，用来称呼过分庞大的系统。

Monolithic 服务器是一个自然而然的想法。对所有请求的处理都是在同一个进程里面实现，可以使用语言的功能来把应用拆分为类、函数以及命名空间。可以在开发者的笔记本上运行和测试应用，并利用发布管线来确认变更都通过测试并部署到生产环境。应用能够用多实例的方式进行水平扩展。

Monolithic 应用是可以成功的，不过随着人数的增加，可能就让人不满了 —— 尤其是更多应用被部署到云环境之中的情况下。即使是应用中的一小部分的变更，也会要求整个应用重建和部署。项目的模块化结构也越来越难于维护，这又导致变更的影响范围很难被限制在模块之内。只能对整个应用的负载进行伸缩，也浪费了更多的资源。

图 1 ：Monoliths 和微服务

Monolithic 应用把所有的功能放入一个进程，只能以应用的粒度进行集群设置。
微服务架构把每个功能元素放入单独的服务中，可以按需对服务进行集群设置。

这些不满造就了微服务这样的架构风格：以一套服务的方式构建应用。每个服务都可以独立的部署和伸缩，每个服务都有严格的边界，甚至可以用不同的语言来开发不同的服务。每个服务也可以被不同的团队来管理。

我们不认为微服务是个创新，他的根基就是 Unix 的设计原则。然而我们认为，使用这一架构思想的人还不够多，否则软件开发的过程会比现在愉快得多。

微服务架构的特性

微服务架构还没有一个正式的定义，然而我们可以尝试描述一下这一架构的特性。当然，并不是说所有微服务架构都会具有所有这些特性，我们希望多数微服务应用能够体现多数的特性。这一社区很松散，我们尝试描述我们自己的团队以及我们知道的其他团队的相关工作，而不是尝试制定一个需要严格尊重的定义。

服务方式实现的组件化

自从我们进入软件工业开始，就重复做着一个美梦——像物理世界一样，用可插接的零件来构建系统。过去二十年中，我们也看到这方面的巨大进步，多数语言平台都有了颇具规模的常规库。

当说起组件时，我们陷入一个困境——如何定义组件？我们说组件是软件的一个可替换的、可升级的单元。

微服务架构也会使用库，但是这一架构实现组件化的方式是把软件拆分为服务。库一般会被 Link 到程序之中，并在内存中被调用；而服务是进程外的组件，只能通过 Web 服务或者远程调用等方式进行调用（这是一概念和很多面向对象的服务对象概念是不同的）

包括我们自己在内的很多面向对象的设计者，在领域驱动设计模型中使用服务对象这个词，用于描述一种没有绑定到实体，但却负载业务过程的对象。这跟本文中使用的“服务”一词是完全不同的概念。很不幸，我们必须忍受这个多义词的困扰。

把服务看成组件（而不是库）的一个主要的原因是，服务是可以独立部署的。如果你有一个应用在单独进程中包含了多个库，对其中任何组件的变更都会导致整个应用的重新部署。如果应用解耦称为多个服务，就可以只对发生变更的服务进行重新部署了。但有些变更会导致服务接口的变更，从而对依赖这一服务的其他服务造成影响，因此独立部署这一特点并不是绝对的。好的微服务架构要通过服务边界的内聚，以及在服务协议中封装升级机制，来减少这种情况的发生。

软件的边界

另外一个用服务做组件的结果就是更直接的组件界面。多数语言并没有一个好的机制来定义一个清晰的公开接口。一般只会有文档和规则来阻止客户端破坏组件的封装，这就会造成组件间的耦合。服务方式则可以比较容易的通过限制远程调用的机制来避免这种情况。

如此使用服务也会有坏处。相比进程内调用，远端调用的成本相对高昂，(为了节省调用成本)，就需要把远程 API 设计成为粗粒度的结构，但这样的话，又会难于使用。如果想要在不同组件之间移动功能，这一难度在使用服务（跨越进程）的情况下会大大增加。

服务似乎可以映射为进程，不过只是似乎。一个服务可以包含很多一起开发和部署的进程，例如一个应用进程和一个该进程专属的数据库。

根据业务功能进行组织

在尝试将一个大应用拆分开来的过程中，一般是着眼于技术层面，代领 UI 团队、服务端团队、以及数据库团队协作完成任务。如此的组织方式下，即使是简单的变更，也需要团队间的协作，需要完成时间和预算的相关流程。有的团队会围绕这一情况进行优化，两害相权取其轻——能访问哪个应用就把逻辑放到哪里。换句话说，逻辑到处都是。这是康威定律的具体体现。

一个组织设计出来的系统，其结构取决于该组织的通讯结构。

Melvyn Conway, 1967

图 2：康威定律

微服务的拆分规则是不同的，是以业务能力维度来进行拆分的。服务实现某种业务能力的一个方面，包括用户界面、持久存储，以及任何的外部协作。因此，这个团队也要是多功能的，具有这项开发任务的所有必要技能：用户体验、数据库以及项目管理。

www.comparethemarket.com 采用了这样的组织结构。具有交叉功能的团队负责建设和运维每个产品，每个产品都被拆分称为一系列独立的服务，服务之间使用消息总线进行通信。

大型的 Monolithic 应用也能围绕业务能力进行模块化。当然我们可以建立一个庞大团队来建立一个按业务线拆分的大应用。这一做法的主要问题是，这样的应用会跨越很多模块，相应的就会具有很多的上下文，团队成员的短期记忆很难适应任务的切换。而且这里面还有一个问题就是，要制定很多的规则，来保证模块的边界。

产品不是项目

我们所见的多数应用开发都是使用项目模型：把完成的软件交付出去。交付之后，完成软件的团队就解散了。

微服务的倡导者们建议避开这种模型，而建议由同一个团队掌握产品的整个生命周期。一个例子就是 Amazon 的 “谁开发谁运行”（You build, you run it），开发团队要承担软件在生产环境的运行情况。这让开发者每天都会关注到产品的运行情况，并增进同用户的沟通，至少会分担一部分支持的责任。

旧有模式把系统看成一堆待开发完成的功能，而产品心态则更进一步——关注软件是否能够帮助用户增强其业务能力。

Monolithic 应用也可以采用这一目标，但是小粒度的服务更容易在用户和开发者之间产生联系。

智能端点和哑管道

当在不同进城之间建立通信结构时，我们会看到很多产品和方法都试图把智能嵌入到通信机制当中去。一个明显的例子就是 ESB，ESB 产品经常会包含消息路由、编排、转换以及业务规则等功能。

微服务社区倾向于另外一种方式：*智能端点和哑管道*。微服务方式构建的应用力求高内聚和低耦合， ——每个服务都像 Unix 中的 Filter 一样工作——接受请求，处理，输出响应。使用简单的 REST 风格的协议，而不是 WX 或者 BPEL 之类的复杂协议。

最常见的两个协议是带有资源 API 的 HTTP 请求-响应以及轻量级消息协议。最好的表达是：

成为 Web，而不是基于 Web
-- Ian Robinson

为了追求伸缩性的极致，有些组织最后会转向 protobufs 这样的二进制协议。使用了这样的协议，仍然是智能端点 + 哑管道的，只是为了性能损失了透明性。对大多数 Web 应用来说是无需做出这样的妥协的——透明本身也是明显的优势。

微服务团队使用的规则和协议，正是互联网的基础。常用的资源可以轻易地由开发或运维人员进行缓存。

另一种常用的方法是轻量级的消息总线。一般会选择哑管道类型（就是说只使用消息路由功能）例如 RabbitMQ 或者 ZeroMQ 这样的产品，除去提供可靠的异步功能，几乎没有其他能力。智能始终存在于生产或消费消息的服务端点。

在 Monolith 应用中，组件在进程内执行，通信是通过方法或者函数的调用来实现的。因此从 Monolith 迁移到微服务的最大问题就是通信方式的改变。简单的从内存方法调用转换为 RPC 并不合适。应该把通信从细粒度转为粗粒度。

去中心化的治理

中心化治理的一个后果就是单技术平台的倾向。经验表明，这种方法有其固有的局限性——不能用一个方案解决所有问题。我们建议用合适的工具对付特定的任务。Monolithic 应用在某些情况下也可以使用多种语言，但这并不是一个常规的情况。

把 Monolith 应用拆分为服务，我们就有了选择每个服务实现方式的机会。用 Node.js 来启动一个简单的报告页面？用 C++ 来完成一些接近实时的任务？为了更好的读取性能而选择其他风格的数据库？每一种问题我们都有办法分开解决了。

当然了，能用/会用什么办法，并不意味着就应该用这种办法。但是经过这样的拆分，你就有了选择。

构建微服务的团队倾向于一种不同的标准化的方法。与纸面规矩不同，我们更愿意制作有用的工具，帮助其他开发者解决类似的问题。这些工具一般来自于项目，分享给更多人，也不排除使用一种内部的开源模型。现在 Git 和 Github 已经成为版本控制系统的事实标准，开源实践也日益盛行。

Netflix 就是一个遵循这种哲学的例子。分享有用的、经过高强度测试的代码，鼓励其他开发者用相似的办法解决相似的问题，对有实际需求的另辟蹊径的解决方法也抱以开放的心态。分享库集中于一些基础问题，包括数据存储、进程间通信以及后面我们会讨论到的——基础设施自动化。

对于微服务社区来说，开销不是个有吸引力的问题。这并不是说社区不重视服务合同（协议），而是因为想要做到更多，Tolerant Reader 和 Consumer Driven 都是微服务中常见的模式。这些服务协议正在独立发展。在服务中采用 Consumer Driven 方式，能够快速获取服务是否正常工作的反馈信息。澳大利亚的一个团队就是使用这种方式。他们利用简单的工具来为服务定义合同。这一自动过程在服务代码编写之前就得以执行。服务只有在满足合同要求时才能被构建，这样在构建新软件的时候，就优雅的规避了 ‘YAGNI’ 困境。这些技术和工具不断成长，通过解耦服务的方式避免了对中心管制的依赖。

YAGNI 或者说“你不需要他”，是一个 XP 原则，在确定需要之前，不要加入新功能。

可能去中心化治理的最高点就是 Amazon 了。一个团队要负责其开发的软件的包括 ²⁴⁄₇ 运维在内的方方面面的工作。放权到这个层次当然不是很常见，不过我们看到越来越多的公司正在把职权推给开发团队。Netflix 是另外一个采用这种办法的公司。每天凌晨三点钟被传呼机叫醒，绝对会提升你编写代码时对质量的警觉度。这种理念同传统的中心治理模型渐行渐远。

Adrian Cockcroft 在 2013 年 11 月的演讲中特别的提到“开发者自助”以及“开发者负责运行”

去中心化的数据管理

数据管理的去中心化有很多的表现形式。在最抽象的层面，他意味着在不同的系统中，世界的模型是不同的。这在大企业的集成过程中很常见，例如在销售视图中一个称为客户的对象，在客服系统中可能完全不同。在不同环境下一个对象可能有不同的属性。

这种情况往往发生在应用之间，不过也可能在应用内部的组件之间发生。领域驱动设计观念中的限界上下文（Bounded Context）是一个有用的思考这一问题的途径。DDD 把一个复杂的域拆分为多个限界上下文，并在中间对关系进行映射。这一过程对 Monolithic 和微服务架构都有效的，不过微服务根据业务能力进行的拆分在这方面更清晰，更接近。

概念模型上的去中心化之外，微服务还对数据存储进行了去中心化。Monolithic 应用倾向于一个单独的逻辑数据库来存储持久化数据，因为数据库厂商的授权方式，企业往往也希望单独的一个数据库为多个应用服务。微服务则更希望每个服务管理自己的数据库，数据库可以是同样的，也可以是完全不同的，这种方式被称为混合持久化( Polyglot Persistence )，当然 Monolithic 应用也可以这样使用，但是这种用法更多的还是出现在微服务架构中。

微服务之间的数据的去中心化，隐含了更新管理的要求。一般的方法是在更新多个资源的时候，利用事务来保证一致性，这种方式在 Monoliths 应用中最为常见。

事务在解决一致性问题的同时，也造成了时间上的耦合，在多服务应用中实现也是有困难的。而分布式事务的难度可以说是街知巷闻了，因此微服务架构强调服务间的非事务协调，只对最终一致性做出保证，其他的问题通过补偿操作进行处理。

如何管理不一致的数据，也给开发团队带来新的挑战，不过这本来也是业务实践过程中常见的情况。现实世界中的业务经常会容忍一定程度的不一致，以此换取快速响应需求的能力，然后用某些反冲过程来处理不一致造成的问题。相对于保证高度一致性的成本，这种对不一致的妥协方式是行之有效的。

基础设施自动化

近年来，针对基础设施的自动化技术取得了长足的进步。云计算、AWS 带来的进步，成功的降低了构建、部署以及运维微服务应用的复杂性。

很多微服务架构的产品和系统都是由具有持续交付或持续集成经验的团队所构建的。这种团队在自动化技术方面有很多应用，下图描述了构建流程：

图 5：基础构建流程

编译，单元和功能测试（Build 环境运行）
验收测试（部署到 Build 环境）
集成测试（部署到集成环境）
用户验收测试（部署到用户验收测试环境）
性能测试（部署到性能测试环境）
发布到生产环境

本文的焦点并非持续交付，因此这里只会提到一些关键点。我们要尽可能的保证我们的软件可以运行，所以要运行很多的自动测试。能够运行的软件在流程中的“前进”意味着自动部署到指定环境。

Monolithic 应用也可以被轻松的 Build，测试和推送到制定环境中。事实证明，一旦应用实现了自动化，那么应用的发布就不再惊悚了。需要强调的是，持续交付的目标就是让部署变得无聊，所以不管是一个还是三个应用，只要是无聊的，就是没有问题的。

这里似乎不够坦诚。很明显发布多个服务是比发布单个的 Monolith 应用更复杂的，幸运的是，这种复杂度可以通过工具化来降低。

另外一个需要自动化的场合就是管理正在生产环境运行的微服务应用。上面提到的部署过程区别并不大，然而在运维过程中，自动化就会产生明显的区别了。

Monolith：多个模块运行在同一进程中。
微服务：模块运行在不同的进程中

图 6：模块部署的区别*

面向故障的设计（Desgin for failure）

既然把服务作为组件来使用，那么自然而然的，应用就应该适当的容忍服务的故障。每个服务的提供者都可能出现调用失败的情况，客户端必须尽可能的对此做出正确的应对。相对于 Monolithic 应用来说，微服务架构在这里引入了更多的复杂性，因此这是微服务架构的劣势之一。后果就是微服务团队必须要考虑服务失败对用户体验的影响。Netflix 的 Simian Army 项目可以模拟服务甚至是数据中心的故障，来检测应用的恢复能力以及监控能力。

服务既然随时可能失败，那么对服务的快速检测，并尽可能的恢复服务，就很重要了。实时监控对于微服务应用来说是至关重要的，监控内容包括架构级别的要素（数据库的每秒请求数量），以及业务相关的维度（例如每分钟订单数）。监控系统应该能够在系统不正常的时候，警告开发人员介入调查。

这对微服务架构来说是很重要的，有了服务编排和事件协作，微服务架构表现了一定的自发性。虽然很多人认为自发行为是一大优势，然而自发行为也有失控的可能。所以监控在这里就至关重要了，当错误的自发行为产生时，能够快速的进行修复。

Monoliths 也可以像微服务一样的透明化——其实本该如此。不同之处在于，微服务架构中，必须知道断开的功能是属于哪个服务哪个进程的。在同一个进程中的话，这一过程就没什么用处了。

微服务团队期望有一个承载日志和监控的仪表盘，来展示服务状态以及业务信息。

迭代设计

微服务的实践者一般都有迭代式设计的背景，他们看到了服务分解这一特性，让开发者能够在控制应用的变更。变更控制并不意味着减少变更，而是说用正确的态度和工具来频繁、快速，可控的对软件进行变更。

尝试把软件系统拆分为组件时，会面对一个决策：怎么拆？一个独立的组件，应该是可以独立升级，并可整体被替换的——也就是说我们可以在不影响相关的其他组件的情况下，重写一个组件。事实上很多微服务组织更进一步，宁愿过分细碎，也不愿参杂不清。

Dan North 更愿意称之为可替换组件架构，而不是微服务。这似乎是我们后面要谈到的特性的一个子集。

Guardian 网站是一个很好的 Monolith 应用的例子，但是也已经像微服务方向发展了。Monolith 仍然是网站的主干，但是他们利用 Monolith 的 API，建立微服务，来实现新的功能。这种办法对一些短期的内部功能非常有效，例如一个体育赛事的专题页面。这种方式搭建的部分页面能够用快速开发的语言迅速上线，然后在赛事结束之后立刻停掉。我们已经在一些金融机构见到类似的做法：为一个市场机会、活动建立新的服务，结束后再将服务下线。

模块化设计的规则中，可替换原则，是一个让设计能够经得住变更的考验的重要部分。要保证同一个模块内的变化能够同步进行。系统中较少改变的部分应该沉淀到稳定的经过实践检验的服务中期。重复的同时修改两个服务的情况是一个应当做出服务合并决策的象征。

Kent Beck 以此作为实施模式中的一个设计规则。

把组件转换为服务，对于进度的保证也是颇有助益的。在 Monolith 应用中，所有的变更都需要完整的构建和部署。在微服务应用中，只需要重新部署发生变更的服务。这样就简化了发布流程，提高了发布效率。随之而来也有一个问题就是，服务的变更可能会破坏该服务的下游应用。传统的对付这一问题的方法是版本控制，不过在微服务世界中，这种办法只是权宜之计，我们要想方设法通过对下游服务的容错设计来应对上有服务的变化。

微服务就是未来？

本文的主要目的在于阐述微服务的思路和规则。通过这一过程，我们明确了微服务架构是值得认真对待的企业应用构建方式。我们以及其他一些团队最近用这种方式实施了很多项目；其中包括 Amazon，Netflix，The Guardian，英国政府数字服务，realestate.com.au 以及 comparethemarket.com。2013 年的会议中充满了转向微服务架构的例子——其中包括 Travis CI。另外，还有很多组织正跃跃欲试——虽然可能不叫微服务（经常还是会被称为 SOA，我们之前也说过，SOA 有很多相互矛盾的表达）

SOA 也不是这一形式的源头。我记得当 SOA 团队在本世纪初出现的时候就有人说——我们几年前就开始做这个了。有一个争论点就是，这种风格很像早期企业中使用的 COBOL 程序，他们利用数据文件来进行通信。另外也有人说微服务跟 Erlang 的编程模型很相近，只不过是套上了企业应用的外衣。

尽管有很多肯定的经验，我们也不希望做出微服务代表软件架构未来的结论。虽然对比 Monolith 有很多优点，然而这一方式资历尚浅，仍需时间检验。

架构方面的决策后果往往要多年以后才能被证明。我们见过具有强烈模块化愿望的优秀团队，开发出的 Monolithic 架构在多年以后轰然坍塌。很多人微服务有清晰的边界，不易被污染，因此这种后果应该不会出现在微服务应用上。然而我们还是需要看到更多的系统，运行更长的时间，才能做出微服务架构已经成熟的判断。

还有影响微服务成熟的因素是，组件化的成功与否，要看软件和组件的契合程度，组件的边界也是很难清楚界定的。虽然通过软件设计和重构能够降低对组件切分的难度，然而组件服务化之后，对进程间通信进行重构的难度是高于原有的进程内调用的。不同服务之间的代码移动非常困难，任何接口的变化都需要在参与方之间进行协调，需要进行更多的兼容考虑，测试也变得更为复杂。

另外一个问题是如果组件的边界设计有问题的话，会让一些本应属于组件内的方法变成服务间的调用，这样的情况增加的不只是复杂性，而且还模糊了功能边界，降低了控制能力。大家都认为小的简单的组件能降低难度，却容易忽略服务之间错综复杂的连接问题。

最后，还需要考虑团队的技能水准。高水准的团队才能更好地掌握新技术。对高水平团队来说很有效的技术可能在低水平团队来说完全无法应用。水平低下的团队是无法做好系统的，不论 Monolith 还是微服务架构，都无法改变这一事实。

还有一个经常被讨论的问题就是，不应该直接进入微服务架构，而是应该以 Monolish 架构开始，然后完成组件化过程，如果 Monolith 无法胜任，才需要迁移到微服务架构。（这种建议并不理想，因为进程内的接口并不一定适合转向服务接口。）

所以我们的建议是谨慎乐观。然而我们毕竟看到了，微服务模式值得一试。用于决策的信息永远都是不完整的，这正是是软件最大的挑战之一，微服务也是一样，现在下结论还为时尚早。