在微服务体系结构中，合理的 API 设计非常重要，因为服务之间的所有数据交换都是通过消息或 API 调用发生的。 API 必须有效，以避免出现琐碎 I/O。 由于服务是由独立工作的团队设计的，API 必须具有完善定义的语义和版本控制方案，使得更新不会中断其他服务。 必须区分两种类型的 API： 客户端应用程序调用的公共 API。 用于服务间通信的后端 API。 这两种用例在某种程度上有不同的要求。 公共 API 必须与客户端应用程序（通常是浏览器应用程序或本机移动应用程序）兼容。 在大多数情况下，这意味着公共 API 将使用基于 HTTP 的 REST。 但是，对于后端 API，需要考虑网络性能。 根据服务的粒度，服务间通信可能会导致大量的网络流量。 服务可能很快就会受到 I/O 的约束。 出于此原因，在序列化速度和有效负载大小等方面的考虑越发重要。 基于 HTTP 的 REST 的一些常见替代方案包括 gRPC、Apache Avro 和 Apache Thrift。 这些协议支持二进制序列化，并且通常比 HTTP 更加高效。 注意事项下面是在选择如何实现 API 时要考虑的事 ...

为微服务体系结构创建可靠的 CI/CD 过程可能很有挑战性。 单个团队必须能够快速可靠地发布服务，而不会干扰其他团队或使应用程序整体不稳定。 本文介绍一个示例 CI/CD 管道，用于将微服务部署到 Kubernetes 服务。 每个团队和项目都不同，因此请不要将本文视为一组硬性且快速的规则。 相反，它旨在作为设计自己的 CI/CD 过程的起点。 Kubernetes 托管微服务的 CI/CD 管道的目标可以总结如下： Teams可以独立生成和部署其服务。 传递 CI 过程的代码更改会自动部署到类似生产的环境中。 管道的每个阶段都强制实施质量入口。 服务的新版本可以与以前的版本并行部署。 假设对于此示例，下面是有关开发团队和基本代码的一些假设： 代码存储库是单一存储库，包含按微服务组织的文件夹。 团队的分库策略以基于主库的开发为基础。 团队使用 发布分支 来管理发布。 将针对每个微服务创建单独的版本。 CI/CD 过程Azure Pipelines AKS 生成、测试和部署微服务。 每个微服务的容器映像存储在Azure 容器注册表。 该团队使用 Helm 图表打包每个微服务。 这 ...

更快的发布周期是微服务体系结构的主要优势之一。 但是，如果没有良好的 CI/CD 流程，你将不会实现微服务承诺的灵活性。 本文介绍挑战，并推荐一些解决问题的方法。 什么是 CI/CD？当我们讨论 CI/CD 时，我们真正讨论几个相关过程：持续集成、持续交付和持续部署。 持续集成。 代码更改经常合并到主分支中。 自动生成和测试过程可确保主分支中的代码始终采用生产质量。 持续交付。 通过 CI 过程的任何代码更改都会自动发布到类似生产的环境。 部署到实时生产环境可能需要人工批准，否则可自动进行。 目标是让代码始终做好部署到生产环境的准备。 持续部署。 通过前两个步骤的代码更改会自动部署到 生产 中。 下面是微服务体系结构的可靠 CI/CD 过程的一些目标： 每个团队可以独立生成并部署自有的服务，而不影响或干扰其他团队。 新服务版本在部署到生产环境之前，会先部署到开发/测试/QA 环境进行验证。 在每个阶段强制实施质量控制。 服务的新版本可以与以前的版本并行部署。 实施足够的访问控制策略。 对于容器化工作负荷，可以信任部署到生产环境的容器映像。 为什么可靠的 CI/C ...

微服务的目标是将应用程序分解为可独立部署的小自治服务，以提高应用程序发布的速度。 微服务体系结构也带来了一些挑战。 此处显示的设计模式可以帮助缓解这些难题。 大使模式 可用于卸载常见的客户端连接任务，例如监视、日志记录、路由 (安全任务，例如，) 与语言无关的 TLS 连接。 代表服务通常部署为 sidecar (请参阅下面的) 。 防腐层模式 实现新应用程序与旧应用程序之间的外观，以确保新应用程序的设计不受限于旧系统的依赖关系。 前端专属的后端模式 不同类型的客户端（如桌面和移动）创建单独的后端服务。 这样一来，单个后端服务就不需要处理各种客户端类型的冲突要求。 此模式可以通过区分特定于客户端的问题来帮助简化每个微服务。 隔板模式 隔离每个工作负荷或服务的关键资源，例如连接池、内存和 CPU。 通过使用隔舱，单个 (或) 无法消耗所有资源，使其他工作负荷耗尽。 此模式通过防止一个服务导致的级联故障，提高系统的复原能力。 网关聚合模式 将多个单个微服务的请求聚合为单个请求，减少使用者和服务之间的通信。 网关卸载模式 使每个微服务能够将共享服务功能（例如 SSL 证书的使用）卸载到 A ...

本文介绍在微服务体系结构中管理数据时的注意事项。 由于每个微服务管理自身的数据，因此，数据完整性和数据一致性是关键的挑战。 微服务的基本原则是每个服务管理其自身的数据。 两个服务不应共享数据存储。 相反，每个服务负责管理维护自身的专用数据存储，其他服务不能直接访问该存储。 制定此规则的原因是避免服务之间出现意外耦合 - 如果服务共享相同的基础数据架构，就会出现这种情况。 如果对数据架构做了某项更改，必须在依赖于该数据库的每个服务之间协调该项更改。 通过隔离每个服务的数据存储，我们可以限制更改范围，并保持真正独立部署的灵活性。 另一个原因是，每个微服务可能有自身的数据模型、查询或读/写模式。 使用共享的数据存储会限制每个团队为其特定服务优化数据存储的能力。 此方法自然会导致 polyglot 持久性 ，即在单个应用程序中使用多个数据存储技术。 一个服务可能需要文档数据库的“读时架构”功能。 另一个服务可能需要 RDBMS 提供的引用完整性。 每个团队可以根据其服务任意做出最佳选择。 有关 Polyglot 持久性一般原则的详细信息，请参阅使用最佳的数据存储完成作业。 备注 服务可以共 ...

在微服务体系结构中，客户端可能与多个前端服务进行交互。 在这种情况下，客户端如何知道要调用哪些终结点？ 引入了新服务或者重构了现有服务时，会发生什么情况？ 服务如何处理 SSL 终止、身份验证和其他问题？ API 网关可以帮助解决这些难题。 什么是 API 网关?API 网关位于客户端与服务之间。 它充当反向代理，将来自客户端的请求路由到服务。 它还可以执行各种横切任务，例如身份验证、SSL 终止和速率限制。 如果未部署网关，则客户端必须直接向前端服务发送请求。 但是，直接向客户端公开服务会造成一些潜在问题： 可能需要编写复杂的客户端代码。 客户端必须跟踪多个终结点，并以弹性方式处理故障。 会在客户端与后端之间造成耦合。 客户端需要知道如何分解各个服务。 因此，客户端维护和服务重构会变得更困难。 单个操作可能需要调用多个服务。 这可能导致客户端和服务器之间的多次网络往返，从而显著增加了延迟时间。 每个面向公众的服务必须处理身份验证、SSL 和客户端速率限制等问题。 服务必须公开客户端友好的协议，例如 HTTP 或 WebSocket。 这限制了 通信协议的选择。 包含公共终结点的服 ...

微服务之间的通信必须高效可靠。 随着许多小型服务交互以完成单个业务活动，这可能是一项挑战。 本文介绍异步消息传递与同步 API 之间的权衡。 然后，我们将了解设计弹性服务间通信时面临的一些难题。 挑战下面是服务间通信存在的主要难题。 本文稍后介绍的服务网格旨在应对其中许多挑战。 复原能力。 任意给定的微服务可能有数十甚至数百个实例。 某个实例可能出于若干原因而发生故障。 可能出现节点级的故障，例如硬件故障或 VM 重新启动。 实例可能崩溃或收到不堪重负的请求，因此无法处理任何新请求。 其中的任何事件都可能导致网络调用失败。 可以借助两种设计模式，以更具弹性的方式发出服务间的网络调用： **重试**。 网络调用可能由于暂时性故障（可自行消失）而失败。 调用方不会彻底失败，而通常会重试特定次数的操作，或者重试到配置的超时期限结束为止。 但是，如果操作不是幂等的，则重试可能导致意外的副作用。 原始调用可能成功，但调用方永远不会获得响应。 如果调用方重试，则可以调用操作两次。 一般而言，重试 POST 或 PATCH 方法并不安全，因为不保证这些方法是幂等的。 **断路器**。 如果失败的请求 ...

“运行模式”指的是计算资源（应用程序在这些资源上运行）的承载模型。 在微服务体系结构方面，有两种方案特别流行： 可管理专用节点 (VM) 上运行的服务的服务业务流程协调程序。 使用函数即服务 (FaaS) 的无服务器体系结构。 尽管这不是仅有的两个选项，但两者是用于构建微服务的成熟方案。 应用程序可以包含这两种方案。 服务业务流程协调程序业务流程协调程序处理与一组服务的部署和管理相关的任务。 这些任务包括在节点上放置服务、监视服务运行状况、重启不正常的服务、对服务实例之间的网络流量进行负载均衡、服务发现、缩放服务实例的数目，以及应用配置更新。 常用业务流程协调程序包括 Kubernetes、Service Fabric、DC/OS 和 Docker Swarm。 容器有时，人们在谈论容器和微服务时将它们看作相同的事物。 尽管不是这样，但您不需要使用容器来构建微服务-容器确实具有一些与微服务特别相关的优点，例如： 可移植性。 容器映像是一个独立包，无需安装库或其他依赖项即可运行。 因此，它们的部署非常轻松。 容器可以快速启动和停止，因此，我们可以运转新的实例来处理更多负载，或者在发 ...

阅读《富兰克林自传》整理。 信条1 节制——欲不可太强 求不可过多 欲望锁链的勒索与绞杀 正视欲望，保持它们的均衡 欲望越小，人生就越幸福 不克制物欲必然会导致失败 放纵声色只会打垮自己 少追求物质，多追求理想 想想拥有什么，而非想要什么 正确地取舍，才能正确地把握命运 让心境永远地离开贪婪 信条2 沉默——避免无聊闲扯，言谈必须有益 谨言慎语，学会留有余地 简洁明了，说完就打住 沉默，并非不善于辞令 装聋作哑可以不战而胜 聒噪不如沉默，息谤得于无言 不和别人做无谓的争辩 鼓舌摇唇，言多必失 绝对不可以唠唠叨叨 不要在背后论人长短 不要做一个沉溺于闲谈的人 信条3 秩序——生活物品要放置有序，工作时间要合理安排 秩序：天国的第一条法规 成功不会青睐做事没有次序、没有条理的人 井然有序可以使你掌握自我 做事分清轻重缓急和主次 要事第一，集中精力做最重要的事 工作环境井然有序可以提高工作效率 养成善用大事表的工作习惯（我在找工作的 充分掌握和支配属于自己的时间 为每一天、每一周制定工作计划 掌握好生活的节奏感 信条4 决心——要做事就须下决心去做，决心要做的事就一定要完成 决心就是认 ...

原文 图1.基于Kubernetes的微服务体系结构 微服务是一种流行的体系结构类型，用于构建可复原、高度可缩放、可独立部署且能快速演变的应用程序。 但是，成功的微服务体系结构需要利用不同的方法来设计和生成应用程序。 微服务体系结构由一系列小型的自治服务组成。 每个服务都是自包含服务，并且应在边界上下文中实现单个业务功能。 边界上下文是业务内的自然划分，提供域模型所在的显式边界。 图2. API网关模式微服务架构 什么是微服务？ 微服务具有规模小、独立和松散耦合的特点。 一个小规模的开发人员团队就能编写和维护一个服务。 每个服务都是一个单独的基本代码，可由小型开发团队管理。 服务可独立部署。 团队可以更新现有服务，而无需重新生成和重新部署整个应用程序。 服务负责暂留自己的数据或外部状态。 这一点与传统模型不同，后者由单独的数据层处理数据暂留。 服务通过定义完善的 API 相互通信。 每个服务的内部实现细节均对其他服务隐藏。 支持 polyglot 编程。 例如，服务无需共享相同的技术堆栈、库或框架。 除了服务本身，典型微服务体系结构中还会出现其他组件： 管理/ ...