云原生架构的原则与实践（Google）

以下是 Google 的云原生架构的原则与最佳实践。对于云原生的架构设计，有很好的指导意义。

云原生架构相比于传统架构的不同点

传统的单体架构，在系统演变到稍微大一点的时候，就变得难以变更，测试，部署，扩展，维护。

云原生架构相比于传统架构，有如下的几个主要不同点：

1. 复杂的系统被分解成一个个的服务，每一个服务可以单独地在容器化环境中测试和部署；
2. 应用利用标准的平台提供的服务，比如 Database, 二进制文件存储，消息，CDN，SSL等；
3. 标准的云平台为你考虑大量的运维的事情，包括：部署、自动扩缩容、配置管理、密码管理、监控、告警，这些服务可以按需部署；
4. 标准化的操作系统、中间件、为开发者提供的语言特定的方案栈，以及由平台或者单独的团队提供的对方案栈的维护和补丁；
5. 一个单独的跨职能团队，可以对整个每个服务的完整软件交付周期负责；

基于云原生的架构有这些好处：

1. 更快的部署；
2. 更可靠的发布；（开发和生产环境高相似度）
3. 更低的成本；
4. 更高的安全性；
5. 更高的可靠性；
6. 更简单，更低成本的合规

同时，云原生的架构模式也有这些 Tradeoff:

1. 所有应用都是分布式的，使得操作中出现大量的远程调用。这意味着需要需要仔细考虑如何处理网络的失败和性能问题，以及生产环境中如何排查、调试问题；
2. 开发人员必须使用平台提供的标准化的OS，中间件，以及应用栈。这使得本地开发变得困难；
3. 架构师需要在系统设计中采纳基于事件驱动的方法，并且拥抱最终一致性；

成功迁移到云原生架构的3个重要原则

从交付新的功能开始，而不是从重写现有系统（衡量指标是交付新功能有多快）；

为云原生设计（尽可能使用云平台的原生服务，包括 db, 消息，cdn，cache，存储；尽可能使用无服务的范式；构建、测试和部署完全自动化；使用平台提供的日志、监控、告警服务）；

设计自治的，松耦合的团队，每个团队可以单独部署和测试自己的服务；

对于如下6个问题回答是是的团队，容易做到架构上的成功：

1. 我们可以对系统的设计进行大规模的更改，而不需要经团队外人员许可;
2. 我们可以对系统的设计进行大规模更改而不依赖其他团队，变更他们的系统，或为其他团队带来较多的工作;
3. 我们可以在不需要与外部团队沟通协调的情况下，完成工作;
4. 我们可以根据需要部署和发布我们的产品或服务，不用考虑它依赖哪些什么服务;
5. 我们可以根据需要做我们的大部分测试，而不需要一个集成测试环境;
6. 我们可以在正常工作时间执行部署，且只有可以忽略不计的停机时间。

基于云原生的微服务架构的设计原则和最佳实践

采用micro services或面向服务的体系结构时,有一些重要的原则和实践,你必须确保你遵循。最好从一开始就严格遵守这些规则，因为以后的改造成本更高。

每个服务都应该有自己的数据库。无论使用关系数据库还是nosql解决方案，每个服务都应该有自己的数据库，其他服务不能访问。当多个服务与同一个数据库通信时，随着时间的推移，这些服务将在数据库层紧密耦合在一起。这些依赖关系阻止了对服务进行独立的测试和部署，使得它们更难更改，部署的风险也更大。

服务应该只在网络上通过它们的公开 api 进行通信。所有服务都应该通过 api 公开它们的行为，而服务之间应该只通过这些api相互通信。不应该有“后门”访问，服务也不应该直接与其他服务的数据库通信。这避免了服务成为紧密耦合的，并确保服务间通信使用良好的文档和受支持的api。

服务负责为其客户端提供向后兼容性。构建和运营服务的团队负责确保对服务的更新不会破坏它的使用者。这意味着计划API版本控制和向后兼容性测试，这样当你发布新版本时，你就不会破坏现有客户。团队可以使用canary release来验证这一点。这还意味着使用蓝/绿部署或分阶段转出等技术，确保部署不会引入停机时间。

创建在开发机器上运行服务的标准方式。开发人员需要能够使用一个命令在开发工作站上按需支持生产服务的任何子集。按需运行服务的 Stub/Mock 版本也应该是可能的——确保您使用许多云服务提供商提供的云服务的 Stub/Mock 版本来帮助您。其目标是使开发人员能够轻松地在本地测试和调试服务。

在产品的监控和可观察性上进行投资。生产环境中的许多问题(包括性能问题)都是紧急的，并且是由多个服务之间的交互引起的。我们的研究表明，有一个能够报告系统整体健康状况的解决方案非常重要(例如，我的系统是否正常运行?我的系统是否有足够的可用资源?)，并且团队可以访问帮助他们跟踪、理解和诊断生产环境中的基础设施问题(包括服务之间的交互)的工具和数据。

为您的服务设置服务级别目标(SLOs)，并定期执行灾难恢复测试。为服务设置SLOs可以为服务的表现设置预期，并帮助您规划，服务在出现故障时系统应如何表现(在构建有弹性的分布式系统时，这是一个关键考虑因素)。使用控制故障注入等技术作为灾难恢复测试计划的一部分，测试生产系统在现实生活中的行为—— Dora 的研究表明，使用这种方法进行灾难恢复测试的组织，更有可能拥有更高级别的服务可用性。你开始的越早越好，这样你就可以使这种重要的活动日常化。

文章翻译自：

https://services.google.com/fh/files/misc/re_architecting_to_cloud_native_whitepaper2.pdf