顶级 CTO 基于五个简单的原则为精心设计的微服务提供建议。

对于从微服务开始的团队来说，最大的挑战之一就是坚持 金发女孩原则 The Goldilocks principle （该典故来自于童话《金发姑娘和三只熊》）：不要太大，不要太小，不能太紧密耦合。之所以是挑战的部分原因是会对究竟什么是设计良好的微服务感到疑惑。

数十位 CTO 通过采访分享了他们的经验，这些对话说明了设计良好的微服务的五个特点。本文将帮助指导团队设计微服务。（有关详细信息，请查看即将出版的书籍 Microservices for Startups，LCTT 译注：已可免费下载完整的电子版）。本文将简要介绍微服务的边界和主观的 “规则”，以避免在深入了解五个特征之前就开始指导您的微服务设计。

微服务边界

使用微服务开发新系统的核心优势之一是该体系结构允许开发人员独立构建和修改各个组件，但在最大限度地减少每个 API 之间的回调数量方面可能会出现问题。根据 SparkPost 工程副总裁 Chris McFadden 所说，解决方案是应用适当的服务边界。

关于边界，与有时难以理解和抽象的领域驱动设计（DDD，一种微服务框架）形成鲜明对比，本文重点介绍了和我们行业的一些顶级 CTO 一同建立的明确定义的微服务边界的实用原则。

避免主观的 “规则”

如果您阅读了足够多的关于设计和创建微服务的建议，您一定会遇到下面的一些 “规则”。 尽管将它们用作创建微服务的指南很有吸引力，但加入这些主观规则并不是思考确定微服务的边界的原则性方式。

“微服务应该有 X 行代码”

让我们直说：微服务中有多少行代码没有限制。微服务不会因为您写了几行额外的代码而突然变成一个独石应用。关键是要确保服务中的代码具有很高的内聚性（稍后将对此进行更多介绍）。

“将每个功能转换为微服务”

如果函数基于三个输入值计算某些内容并返回结果，它是否是微服务的理想候选项？它是否应该是单独可部署应用程序？这确实取决于该函数是什么以及它是如何服务于整个系统。将每个函数转换为微服务在您的情景中可能根本没有意义。

其他主观规则包括不考虑整个情景的规则，例如团队的经验、DevOps 能力、服务正在执行的操作以及数据的可用性需求。

精心设计的服务的 5 个特点

如果您读过关于微服务的文章，您无疑会遇到有关设计良好的服务的建议。简单地说，高内聚和低耦合。如果您不熟悉这些概念，有许多文章关于这些概念的文章。虽然它们提供了合理的建议，但这些概念是相当抽象的。基于与经验丰富的 CTO 们的对话，下面是在创建设计良好的微服务时需要牢记的关键特征。

1：不与其他服务共享数据库表

在 SparkPost 的早期，Chris McFadden 和他的团队必须解决每个 SaaS 业务需要面对的问题：它们需要提供基本服务，如身份验证、帐户管理和计费。

为了解决这个问题，他们创建了两个微服务：用户 API 和帐户 API。用户 API 将处理用户帐户、API 密钥和身份验证，而帐户 API 将处理所有与计费相关的逻辑。这是一个非常合乎逻辑的分离 —— 但没过多久，他们发现了一个问题。

McFadden 解释说，“我们有一个名为‘用户 API’的服务，还有一个名为‘帐户 API’的服务。问题是，他们之间实际上有几个来回的调用。因此，您会在帐户服务中执行一些操作，然后调用并终止于用户服务，反之亦然”

这两个服务的耦合太紧密了。

在设计微服务时，如果您有多个服务引用同一个表，则它是一个危险的信号，因为这可能意味着您的数据库是耦合的源头。

这确实是关于服务与数据的关系，这正是 Swiftype SRE，Elastic 的负责人 Oleksiy Kovrin 告诉我。他说，“我们在开发新服务时使用的主要基本原则之一是，它们不应跨越数据库边界。每个服务都应依赖于自己的一组底层数据存储。这使我们能够集中访问控制、审计日志记录、缓存逻辑等。”

Kovrin 接着解释说，如果数据库表的某个子集“与数据集的其余部分没有或很少连接，则这是一个强烈的信号，表明该组件可以被隔离到单独的 API 或单独的服务中”。

Lead Honestly 的联合创始人 Darby Frey 与此的观点相呼应：“每个服务都应该有自己的表并且永远不应该共享数据库表。”

2：数据库表数量最小化

微服务的理想尺寸应该足够小，但不能太小。每个服务的数据库表的数量也是如此。

Scaylr 的工程主管 Steven Czerwinski 在接受采访时解释说 Scaylr 的最佳选择是“一个或两个服务的数据库表。”

SparkPost 的 Chris McFadden 表示同意：“我们有一个 suppression 微服务，它处理、跟踪数以百万计和数十亿围绕 suppression 的条目，但它们都非常专注于围绕 suppression，所以实际上只有一个或两个表。其他服务也是如此，比如 webhooks。

3：考虑有状态和无状态

在设计微服务时，您需要问问自己它是否需要访问数据库，或者它是否是处理 TB 级数据 (如电子邮件或日志) 的无状态服务。

Algolia 的 CTO Julien Lemoine 解释说：“我们通过定义服务的输入和输出来定义服务的边界。有时服务是网络 API，但它也可能是使用文件并在数据库中生成记录的进程 (这就是我们的日志处理服务)。”

事先要明确是否有状态，这将引导一个更好的服务设计。

4：考虑数据可用性需求

在设计微服务时，请记住哪些服务将依赖于此新服务，以及在该数据不可用时的整个系统的影响。考虑到这一点，您可以正确地设计此服务的数据备份和恢复系统。

Steven Czerwinski 提到，在 Scaylr 由于关键客户行空间映射数据的重要性，它将以不同的方式复制和分离。

相比之下，他补充说，“每个分片信息，都在自己的小分区里。如果部分客户群体因为没有可用日志而停止服务那很糟糕，但它只影响 5% 的客户，而不是100% 的客户。”

5：单一的真实来源

设计服务，使其成为系统中某些内容的唯一真实来源。

例如，当您从电子商务网站订购内容时，则会生成订单 ID，其他服务可以使用此订单 ID 来查询订单服务，以获取有关订单的完整信息。使用 发布/订阅模式，在服务之间传递的数据应该是订单 ID ，而不是订单本身的属性信息。只有订单服务具有订单的完整信息，并且是给定订单信息的唯一真实来源。

大型团队的注意事项

考虑到上面列出的五个注意事项，较大的团队应了解其组织结构对微服务边界的影响。

对于较大的组织，整个团队可以专门拥有服务，在确定服务边界时，组织性就会发挥作用。还有两个需要考虑的因素：独立的发布计划和不同的正常运行时间的重要性。

Cloud66. 的 CEO Khash Sajadi 说：“我们所看到的微服务最成功的实现要么基于类似领域驱动设计这样的软件设计原则 (如面向服务的体系结构)，要么基于反映组织方法的设计原则。”

“所以 (对于) 支付团队” Sajadi 说，“他们有支付服务或信用卡验证服务，这就是他们向外界提供的服务。所以这不一定是关于软件的。这主要是关于为外界提供更多服务的业务单位。”

双披萨原理

Amazon 是一个拥有多个团队的大型组织的完美示例。正如在一篇发表于 API Evangelist 的文章中所提到的，Jeff Bezos 向所有员工发布一项要求，告知他们公司内的每个团队都必须通过 API 进行沟通。任何不这样做的人都会被解雇。

这样，所有数据和功能都通过该接口公开。Bezos 还设法让每个团队解耦，定义他们的资源，并通过 API 提供。Amazon 正在从头建立一个系统。这使得公司内的每一支团队都能成为彼此的合作伙伴。

我与 Iron.io 的 CTO Travis Reeder 谈到了 Bezos 的内部倡议。

“Jeff Bezos 规定所有团队都必须构建 API 才能与其他团队进行沟通，” Reeder 说。“他也是提出‘双披萨’规则的人：一支团队不应该比两个比萨饼能养活的大。”

“我认为这里也可以适用同样的方法：无论一个小型团队是否能够开发、管理和富有成效。如果它开始变得笨重或开始变慢，它可能变得太大了。” Reeder 告诉我。

最后注意事项: 您的服务是否具有合适的大小和正确的定义？

在微服务系统的测试和实施阶段，有一些指标需要记住。

指标 #1: 服务之间是否存在过度依赖？

如果两个服务不断地相互回调，那么这就是强烈的耦合信号，也是它们可能更好地合并为一个服务的信号。

回到 Chris McFadden 的例子， 他有两个 API 服务，帐户服务和用户服务不断地相互通信， McFadden 提出了一个合并服务的想法，并决定将其称为 “账户用户 API”。事实证明，这是一项富有成效的战略。

“我们开始做的是消除这些内部 API 之间调用的链接，” McFadden 告诉我。“这有助于简化代码。”

指标 #2: 设置服务的开销是否超过了服务独立的好处？

Darby Frey 解释说，“每个应用都需要将其日志聚合到某个位置，并需要进行监视。你需要设置它的警报。你需要有标准的操作程序，和在出现问题时的操作手册。您必须管理 SSH 对它的访问。只是为了让一个应用运行起来，就有大量的基础性工作必须存在。”

关键要点

设计微服务往往会让人感觉更像是一门艺术，而不是一门科学。对工程师来说，这可能并不顺利。有很多一般性的建议，但有时可能有点太抽象了。让我们回顾一下在设计下一组微服务时要注意的五个具体特征：

1. 不与其他服务共享数据库表
2. 数据库表数量最小化
3. 考虑有状态和无状态
4. 考虑数据可用性需求
5. 单一的真实来源

下次设计一组微服务并确定服务边界时，回顾这些原则应该会使任务变得更容易。

via: https://opensource.com/article/18/4/guide-design-microservices

作者：Jake Lumetta 选题：lujun9972 译者：lixinyuxx 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

微服务是个好东西，就像乐高积木一样，你可以拼成各种东西，当前，前提是你足够会玩。

从早些年的 SOA 和中间件，到现在的微服务和容器，但似乎历史总是螺旋式变化的。看起来笨拙而大而无当的独石应用，其实在很多场景，要比微服务更适合。

话说，微服务的锅该那只汤姆猫背吗？:->

via: http://turnoff.us/geek/are-you-ready-for-microservices/

作者：Daniel Stori 译者&点评&校对：wxy 合成：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在现代微服务环境中，构建小型、单一的应用程序的旧策略又再一次流行了起来。

1984 年，Rob Pike 和 Brian W. Kernighan 在 AT&T 贝尔实验室技术期刊上发表了名为 “Unix 环境编程” 的文章，其中他们使用 BSD 的 cat -v 例子来认证 Unix 哲学。简而言之，Unix 哲学是：构建小型、单一的应用程序 —— 不管用什么语言 —— 只做一件小而美的事情，用 stdin / stdout 进行通信，并通过管道进行连接。

听起来是不是有点耳熟？

是的，我也这么认为。这就是 James Lewis 和 Martin Fowler 给出的 微服务的定义 。

简单来说，微服务架构的风格是将单个 应用程序开发为一套小型服务的方法，每个服务都运行在它的进程中，并用轻量级机制进行通信，通常是 HTTP 资源 API 。

虽然一个 *nix 程序或者是一个微服务本身可能非常局限甚至不是很有用，但是当这些独立工作的单元组合在一起的时候就显示出了它们真正的好处和强大。

*nix程序 vs 微服务

下面的表格对比了 *nix 环境中的程序（例如 cat 或 lsof）与微服务环境中的程序。

让我们详细的看看每一行。

执行单元

*nix 系统（如 Linux）中的执行单元是一个可执行的文件（二进制或者是脚本），理想情况下，它们从 stdin 读取输入并将输出写入 stdout。而微服务通过暴露一个或多个通信接口来提供服务，比如 HTTP 和 gRPC API。在这两种情况下，你都会发现无状态示例（本质上是纯函数行为）和有状态示例，除了输入之外，还有一些内部（持久）状态决定发生了什么。

数据流

传统的，*nix 程序能够通过管道进行通信。换句话说，我们要感谢 Doug McIlroy，你不需要创建临时文件来传递，而可以在每个进程之间处理无穷无尽的数据流。据我所知，除了我在 2017 年做的基于 Apache Kafka 小实验，没有什么能比得上管道化的微服务了。

可配置和参数化

你是如何配置程序或者服务的，无论是永久性的服务还是即时的服务？是的，在 *nix 系统上，你通常有三种方法：命令行参数、环境变量，或全面的配置文件。在微服务架构中，典型的做法是用 YAML（或者甚至是 JSON）文档，定制好一个服务的布局和配置以及依赖的组件和通信、存储和运行时配置。例如 Kubernetes 资源定义、Nomad 工作规范 或 Docker 编排 文档。这些可能参数化也可能不参数化；也就是说，除非你知道一些模板语言，像 Kubernetes 中的 Helm，否则你会发现你使用了很多 sed -i 这样的命令。

发现

你怎么知道有哪些程序和服务可用，以及如何使用它们？在 *nix 系统中通常都有一个包管理器和一个很好用的 man 页面；使用它们，应该能够回答你所有的问题。在微服务的设置中，在寻找一个服务的时候会相对更自动化一些。除了像 Airbnb 的 SmartStack 或 Netflix 的 Eureka 等可以定制以外，通常还有基于环境变量或基于 DNS 的方法，允许您动态的发现服务。同样重要的是，事实上 OpenAPI 为 HTTP API 提供了一套标准文档和设计模式，gRPC 为一些耦合性强的高性能项目也做了同样的事情。最后非常重要的一点是，考虑到开发者经验（DX），应该从写一份好的 Makefile 开始，并以编写符合 风格 的文档结束。

优点和缺点

*nix 系统和微服务都提供了许多挑战和机遇。

模块性

要设计一个简洁、有清晰的目的，并且能够很好地和其它模块配合的某个东西是很困难的。甚至是在不同版本中实现并引入相应的异常处理流程都很困难的。在微服务中，这意味着重试逻辑和超时机制，或者将这些功能外包到 服务网格 service mesh 是不是一个更好的选择呢？这确实比较难，可如果你做好了，那它的可重用性是巨大的。

可观测性

在一个 独石 monolith （2018 年）或是一个试图做任何事情的大型程序（1984 年），当情况恶化的时候，应当能够直接的找到问题的根源。但是在一个

yes | tr \\n x | head -c 450m | grep n

或者在一个微服务设置中请求一个路径，例如，涉及 20 个服务，你怎么弄清楚是哪个服务的问题？幸运的是，我们有很多标准，特别是 OpenCensus 和 OpenTracing。如果您希望转向微服务，可预测性仍然可能是最大的问题。

全局状态

对于 *nix 程序来说可能不是一个大问题，但在微服务中，全局状态仍然是一个需要讨论的问题。也就是说，如何确保有效的管理本地化（持久性）的状态以及尽可能在少做变更的情况下使全局保持一致。

总结一下

最后，问题仍然是：你是否在使用合适的工具来完成特定的工作？也就是说，以同样的方式实现一个特定的 *nix 程序在某些时候或者阶段会是一个更好的选择，它是可能在你的组织或工作过程中的一个最好的选择。无论如何，我希望这篇文章可以让你看到 Unix 哲学和微服务之间许多强有力的相似之处。也许我们可以从前者那里学到一些东西使后者受益。

via: https://opensource.com/article/18/11/revisiting-unix-philosophy-2018

作者：Michael Hausenblas 选题：lujun9972 译者：Jamskr 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果我告诉你有这样一种软件架构，一个应用程序的组件通过基于网络的通讯协议为其它组件提供服务，我估计你可能会说它是 …

是的，它和你编程的年限有关。如果你从上世纪九十年代就开始了你的编程生涯，那么你肯定会说它是 面向服务的架构 Service-Oriented Architecture （SOA）。但是，如果你是个年青人，并且在云上获得初步的经验，那么，你将会说：“哦，你说的是 微服务 Microservices 。”

你们都没错。如果想真正地了解它们的差别，你需要深入地研究这两种架构。

在 SOA 中，服务是一个功能，它是定义好的、自包含的、并且是不依赖上下文和其它服务的状态的功能。总共有两种服务。一种是消费者服务，它从另外类型的服务 —— 提供者服务 —— 中请求一个服务。一个 SOA 服务可以同时扮演这两种角色。

SOA 服务可以与其它服务交换数据。两个或多个服务也可以彼此之间相互协调。这些服务执行基本的任务，比如创建一个用户帐户、提供登录功能、或验证支付。

与其说 SOA 是模块化一个应用程序，还不如说它是把分布式的、独立维护和部署的组件，组合成一个应用程序。然后在服务器上运行这些组件。

早期版本的 SOA 使用面向对象的协议进行组件间通讯。例如，微软的 分布式组件对象模型 Distributed Component Object Model （DCOM） 和使用 通用对象请求代理架构 Common Object Request Broker Architecture （CORBA） 规范的 对象请求代理 Object Request Broker （ORB）。

用于消息服务的最新的版本，有 Java 消息服务 Java Message Service （JMS）或者 高级消息队列协议 Advanced Message Queuing Protocol （AMQP）。这些服务通过 企业服务总线 Enterprise Service Bus （ESB） 进行连接。基于这些总线，来传递和接收可扩展标记语言（XML）格式的数据。

微服务 是一个架构样式，其中的应用程序以松散耦合的服务或模块组成。它适用于开发大型的、复杂的应用程序的 持续集成 Continuous Integration / 持续部署 Continuous Deployment （CI/CD）模型。一个应用程序就是一堆模块的汇总。

每个微服务提供一个应用程序编程接口（API）端点。它们通过轻量级协议连接，比如， 表述性状态转移 REpresentational State Transfer （REST），或 gRPC。数据倾向于使用 JavaScript 对象标记 JavaScript Object Notation （JSON）或 Protobuf 来表示。

这两种架构都可以用于去替代以前老的整体式架构，整体式架构的应用程序被构建为单个的、自治的单元。例如，在一个客户机 —— 服务器模式中，一个典型的 Linux、Apache、MySQL、PHP/Python/Perl (LAMP) 服务器端应用程序将去处理 HTTP 请求、运行子程序、以及从底层的 MySQL 数据库中检索/更新数据。所有这些应用程序“绑”在一起提供服务。当你改变了任何一个东西，你都必须去构建和部署一个新版本。

使用 SOA，你可以只改变需要的几个组件，而不是整个应用程序。使用微服务，你可以做到一次只改变一个服务。使用微服务，你才能真正做到一个解耦架构。

微服务也比 SOA 更轻量级。不过 SOA 服务是部署到服务器和虚拟机上，而微服务是部署在容器中。协议也更轻量级。这使得微服务比 SOA 更灵活。因此，它更适合于要求敏捷性的电商网站。

说了这么多，到底意味着什么呢？微服务就是 SOA 在容器和云计算上的变种。

老式的 SOA 并没有离我们远去，而因为我们不断地将应用程序搬迁到容器中，所以微服务架构将越来越流行。

via: https://blogs.dxc.technology/2018/05/08/everything-old-is-new-again-microservices/

作者：Cloudy Weather 选题：lujun9972 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

任何一种架构都是有利有弊的，而能满足你组织的独特需要的决策才是正确的选择。

对于许多初创公司来说，传统的知识认为，从单一整体架构开始，而不是使用微服务。但是，我们还有别的选择吗？

这本新书 —— 《初创公司的微服务》，从许多 CIO 们理解的微服务的角度，解释了微服务的优点与缺点。

对于初创公司，虽然不同的 CTO 对此给出的建议是不同的，但是他们都一致认为环境和性能很重要。如果你正考虑你的业务到底是采用微服务还是单一整体架构更好，下面讨论的这些因素正好可以为你提供一些参考。

理解范围

首先，我们先来准确定义我们所谓的 “整体服务” 和 “微服务” 是什么。

微服务是一种方法，它开发一个单一的应用程序来作为构成整体服务的小服务，每个小服务都运行在它自己的进程中，并且使用一个轻量级的机制进行通讯，通常是一个 HTTP 资源的 API。这些服务都围绕业务能力来构建，并且可依赖全自动部署机制来独立部署。

一个整体应用程序是按单个的、统一的单元来构建，并且，通常情况下它是基于一个大量的代码来实现的。一般来说，一个整体服务是由三部分组成的：数据库、客户端用户界面（由 HTML 页面和/或运行在浏览器中的 JavaScript 组成）、以及服务器端应用程序。

“系统架构处于一个范围之中”，Zachary Crockett，Particle 的 CTO，在一次访谈中，他说，“在讨论微服务时，人们倾向于关注这个范围的一端：许多极小的应用程序给其它应用程序传递了过多的信息。在另一端，有一个巨大的整体服务做了太多的事情。在任何现实中的系统上，在这两个极端之间有很多合适的面向服务的架构”。

根据你的情况不同，不论是使用整体服务还是微服务都有很多很好的理由。

“我们希望为每个服务使用最好的工具”，Julien Lemoine 说，他是 Algolia 的 CTO。

与很多人的想法正好相反，整体服务并不是过去遗留下来的过时的架构。在某些情况下，整体服务是非常理想的。我采访了 Steven Czerwinski 之后，更好地理解了这一点，他是 Scaylr 的工程主管，前谷歌员工。

“尽管我们在谷歌时有使用微服务的一些好的经验，我们现在 [在 Scalyr] 却使用的是整体服务的架构，因为一个整体服务架构意味着我们的工作量更少，我们只有两位工程师。“ 他解释说。（采访他时，Scaylr 正处于早期阶段）

但是，如果你的团队使用微服务的经验很丰富，并且你对你们的发展方向有明确的想法，微服务可能是一个很好的替代者。

Julien Lemoine，Algolia 的 CTO，在这个问题上，他认为：“我们通常从使用微服务开始，主要目的是我们可以使用不同的技术来构建我们的服务，因为如下的两个主要原因：

• 我们想为每个服务使用最好的工具。我们的搜索 API 是在底层做过高度优化的，而 C++ 是非常适合这项工作的。他说，在任何其它地方都使用 C++ 是一种生产力的浪费，尤其是在构建仪表板方面。
• 我们希望使用最好的人才，而只使用一种技术将极大地限制我们的选择。这就是为什么在公司中有不同语言的原因。

”

如果你的团队已经准备好从一开始就使用微服务，这样你的组织从一开始就可以适应微服务环境的开发节奏。

权衡利弊

在你决定那种方法更适合你的组织之前，考虑清楚每种方法的优缺点是非常重要的。

整体服务

优点：

• 很少担心横向联系： 大多数应用程序开发者都担心横向联系，比如，日志、速度限制、以及像审计跟踪和 DoS 防护这样的安全特性。当所有的东西都运行在同一个应用程序中时，通过组件钩子来处理这些关注点就非常容易了。
• 运营开销很少： 只需要为一个应用程序设置日志、监视、以及测试。一般情况下，部署也相对要简单。
• 性能： 一个整体的架构可能会有更好的性能，因为共享内存的访问速度要比进程间通讯（IPC）更快。

缺点：

• 紧耦合： 整体服务的应用程序倾向于紧耦合，并且应用程序是整体进化的，分离特定用途的服务是非常困难的，比如，独立扩展或者代码维护。
• 理解起来很困难： 当你想查看一个特定的服务或者控制器时，因为依赖、副作用、和其它的不可预见因素，整体架构理解起来更困难。

微服务

优点：

• 非常好组织： 微服务架构一般很好组织它们，因为每个微服务都有一个特定的工作，并且还不用考虑其它组件的工作。
• 解耦合： 解耦合的服务是能够非常容易地进行重组织和重配置，以服务于不同的应用程序（比如，同时向 Web 客户端和公共 API 提供服务）。它们在一个大的集成系统中，也允许快速、独立分发单个部分。
• 性能： 根据组织的情况，微服务可以提供更好的性能，因为你可以分离热点服务，并根据其余应用程序的情况来扩展它们。
• 更少的错误： 微服务允许系统中的不同部分，在维护良好边界的前提下进行并行开发。这样将使连接不该被连接的部分变得更困难，比如，需要连接的那些紧耦合部分。

缺点：

• 跨每个服务的横向联系点： 由于你构建了一个新的微服务架构，你可能会发现在设计时没有预料到的很多横向联系的问题。这也将导致需要每个横向联系点的独立模块（比如，测试）的开销增加，或者在其它服务层面因封装横向联系点，所导致的所有流量都需要路由。最终，即便是整体服务架构也倾向于通过横向联系点的外部服务层来路由流量，但是，如果使用整体架构，在项目更加成熟之前，也不过只是推迟了工作成本。
• 更高的运营开销： 微服务在它所属的虚拟机或容器上部署非常频繁，导致虚拟机争用激增。这些任务都是使用容器管理工具进行频繁的自动化部署的。

决策时刻

当你了解了每种方法的利弊之后，如何在你的初创公司使用这些信息？通过与这些 CTO 们的访谈，这里有三个问题可以指导你的决策过程：

你是在熟悉的领域吗？

如果你的团队有以前的一些领域的经验（比如，电子商务）和了解你的客户需求，那么分割成微服务是低风险的。如果你从未做过这些，从另一个角度说，整体服务或许是一个更安全的选择。

你的团队做好准备了吗？

你的团队有使用微服务的经验吗？如果明年，你的团队扩充到现在的四倍，将为微服务提供更好的环境？评估团队大小对项目的成功是非常重要的。

你的基础设施怎么样？

实施微服务，你需要基于云的基础设施。

David Strauss，Pantheon 的 CTO，他解释说："[以前]，你使用整体服务是因为，你希望部署在一个数据库上。每个单个的微服务都需要配置数据库服务器，然后，扩展它将是一个很重大的任务。只有大的、技术力量雄厚的组织才能做到。现在，使用像谷歌云和亚马逊 AWS 这样的云服务，为部署一个小的东西而不需要为它们中的每个都提供持久存储，对于这种需求你有很多的选择。“

评估业务风险

技术力量雄厚的初创公司为追求较高的目标，可以考虑使用微服务。但是微服务可能会带来业务风险。Strauss 解释说，“许多团队一开始就过度构建他们的项目。每个人都认为，他们的公司会成为下一个 ‘独角兽’，因此，他们使用微服务构建任何一个东西，或者一些其它的高扩展性的基础设施。但是这通常是一种错误的做法”。Strauss 说，在那种情况下，他们认为需要扩大规模的领域往往并不是一开始真正需要扩展的领域，最后的结果是浪费了时间和努力。

态势感知

最终，环境是关键。以下是一些来自 CTO 们的提示：

什么时候使用整体服务

• 你的团队还在创建阶段： 你的团队很小 —— 也就是说，有 2 到 5 位成员 —— 还无法应对大范围、高成本的微服务架构。
• 你正在构建的是一个未经证实的产品或者概念验证： 如果你将一个全新的产品推向市场，随着时间的推移，它有可能会成功，而对于一个快速迭代的产品，整体架构是最合适的。这个提示也同样适用于概念验证，你的目标是尽可能快地学习，即便最终你可能会放弃它。
• 你没有使用微服务的经验： 除非你有合理的理由证明早期学习阶段的风险可控，否则，一个整体的架构更适用于一个没有经验的团队。

什么时候开始使用微服务

• 你需要快速、独立的分发服务： 微服务允许在一个大的集成系统中快速、独立分发单个部分。请注意，根据你的团队规模，获取与整体服务的比较优势，可能需要一些时间。
• 你的平台中的某些部分需要更高效： 如果你的业务要求集中处理 PB 级别的日志卷，你可能需要使用一个像 C++ 这样的更高效的语言来构建这个服务，尽管你的用户仪表板或许还是用 Ruby on Rails 构建的。
• 计划扩展你的团队： 使用微服务，将让你的团队从一开始就开发独立的小服务，而服务边界独立的团队更易于按需扩展。

要决定整体服务还是微服务更适合你的组织，要坦诚并正确认识自己的环境和能力。这将有助于你找到业务成长的最佳路径。

关于作者

jakelumetta - Jake 是 ButterCMS 的 CEO，它是一个 API-first CMS。他喜欢搅动出黄油双峰，以及构建让开发者工作更舒适的工具，喜欢他的更多内容，请在 Twitter 上关注 @ButterCMS，订阅 他的博客。关于他的更多信息……

via: https://opensource.com/article/18/1/how-choose-between-monolith-microservices

作者：jakelumetta 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你可能并不想把所有的遗留应用全部分解为微服务，或许你可以考虑从安全功能开始。

我为了给这篇文章起个标题，使出 “洪荒之力”，也很担心这会变成标题党。如果你点击它，是因为它激起了你的好奇，那么我表示抱歉 ^注1 。我当然是希望你留下来阅读的 ^注2 ：我有很多有趣的观点以及很多 ^注3 脚注。我不是故意提出微服务会导致安全问题——尽管如同很多组件一样都有安全问题。当然，这些微服务是那些安全方面的人员的趣向所在。进一步地说，我认为对于那些担心安全的人来说，它们是优秀的架构。

为什么这样说？这是个好问题，对于我们这些有系统安全 经验的人来说，此时这个世界才是一个有趣的地方。我们看到随着带宽便宜了并且延迟降低了，分布式系统在增长。加上部署到云愈加便利，越来越多的架构师们开始意识到应用是可以分解的，不只是分成多个层，并且层内还能分为多个组件。当然，均衡负载可以用于让一个层内的各个组件协同工作，但是将不同的服务输出为各种小组件的能力导致了微服务在设计、实施和部署方面的增长。

所以，到底什么是微服务呢？我同意维基百科的定义，尽管没有提及安全性方面的内容 ^注4 。 我喜欢微服务的一点是，经过精心设计，其符合 Peter H. Salus 描述的 UNIX 哲学 的前俩点：

1. 程序应该只做一件事，并尽可能把它做好。
2. 让程序能够互相协同工作。
3. 应该让程序处理文本数据流，因为这是一个通用的接口。

三者中最后一个有点不太相关，因为 UNIX 哲学通常被用来指代独立应用，它常有一个实例化的命令。但是，它确实包含了微服务的基本要求之一：必须具有“定义明确”的接口。

这里的“定义明确”，我指的不仅仅是可外部访问的 API 的方法描述，也指正常的微服务输入输出操作——以及，如果有的话，还有其副作用。就像我之前的文章描述的，“良好的系统架构的五个特征”，如果你能够去设计一个系统，数据和主体描述是至关重要的。在此，在我们的微服务描述上，我们要去看看为什么这些是如此重要。因为对我来说，微服务架构的关键定义是可分解性。如果你要分解 ^注5 你的架构，你必须非常、非常地清楚每个细节（“组件”）要做什么。

在这里，就要开始考虑安全了。特定组件的准确描述可以让你：

• 审查您的设计
• 确保您的实现符合描述
• 提出可重用测试单元来审查功能
• 跟踪实施中的错误并纠正错误
• 测试意料之外的产出
• 监视不当行为
• 审核未来可能的实际行为

现在，这些微服务能用在一个大型架构里了吗？是的。但如果实体是在更复杂的配置中彼此链接或组合在一起，它们会随之越来越难。当你让一小部分可以彼此配合工作时，确保正确的实施和行为是非常、非常容易的。并且如果你不能确定单个组件正在做它们应该作的，那么确保其衍生出来的复杂系统的正确行为及不正确行为就困难的多了。

而且还不止于此。如我已经在许多以往场合提过的，写足够安全的代码是困难的 ^注7 ，证实它应该做的更加困难。因此，有理由限制有特定安全要求的代码——密码检测、加密、加密密钥管理、授权等等——将它们变成小而定义明确的代码块。然后你就可以执行我上面提及所有工作，以确保正确完成。

还有，我们都知道并不是每个人都擅长于编写与安全相关的代码。通过分解你的体系架构，将安全敏感的代码限制到定义明确的组件中，你就可以把你最棒的安全人员放到这方面，并限制了 J.佛系.码奴 ^注8 绕过或降级一些关键的安全控制措施的危险。

它可以作为学习的机会：它对于设计/实现/测试/监视的兄弟们都是好的，而且给他们说：“听、读、标记、学习，并且引为己用 ^注9 。这是应该做的。”

是否应该将所有遗留应用程序分解为微服务？ 不一定。 但是考虑到其带来的好处，你可以考虑从安全入手。

• 注1、有一点——有读者总是好的。
• 注2、这是我写下文章的意义。
• 注3、可能没那么有趣。
• 注4、在我写这篇文章时。我或你们中的一个可能会去编辑改变它。
• 注5、这很有趣，听起来想一个园艺术语。并不是说我很喜欢园艺，但仍然... ^注6
• 注6、有意思的是，我最先写的 “如果你要分解你的架构....” 听起来想是一个 IT 主题的谋杀电影标题。
• 注7、长期读者可能会记得提到的优秀电影 “The Thick of It”
• 注8、其他的什么人：请随便选择。
• 注9、不是加密 摘要 digest ：我不认同原作者的想法。

这篇文章最初出在爱丽丝、伊娃与鲍伯——一个安全博客上，并被许可转载。

via: https://opensource.com/article/17/11/microservices-are-security-issue

作者：Mike Bursell 译者：erlinux 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出