架构学习指导

是否需要设计？

设计是不可或缺的。不做设计并不能节约成本。而过度设计也会造成浪费，这些都需要注意。

阅读推荐

大型网站技术架构：核心原理与案例分析 - 简明扼要，适合刚入门Web开发的程序员

常规教材

系统架构设计师教程 - 针对软考，考高级系统架构设计师的人员必读。

DDD 领域驱动设计

由小伙伴Endlex传教，好的微服务架构设计，离不开DDD的指导。后面专门整理一个笔记做记录。

领域驱动设计精粹    入门必读，也是DDD领域较新的书籍
实现领域驱动设计    进阶必读，个人建议看完上面的再看这本（和上面那本是一个作者）
领域驱动设计：软件核心复杂性应对之道    这本也不错，可以做扩展阅读

有效设计(Effective Design)

有效设计可以满足商业组织希望借助软件超越竞争者的诉求。它可以驱动企业去思考哪些核心业务必须成为其竞争力，还可以指引构建正确软件模型的方向。

12要素应用(Twelve‑Factor App)

由Heroku创始人Adam Wiggins发布，这个设计原则对SaaS平台非常具有指导意义。

12-Factor 为构建如下的 SaaS 应用提供了方法论：

使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

微服务应用的十二个因素

1 - Codebase

一份基准代码，多份部署 Twelve-Factor App为每个应用推荐一个代码库。在微服务架构中，正确的方法实际上是每个服务的一个代码库。此外，我们强烈建议使用Git作为存储库，因为它具有丰富的功能集和巨大的生态系统。GitHub已经成为开源社区的默认Git托管平台，但根据贵组织的需求，还有许多其他优秀的Git托管选项。

2 - 依赖关系

显式声明依赖关系

正如The Twelve-Factor App中所建议的那样，无论您的应用程序在哪个平台上运行，都要使用您的语言或框架附带的依赖关系管理器。您如何安装操作系统或平台依赖性取决于平台： - 在非集成环境中，使用配置管理工具（Chef，Puppet，Ansible）来安装系统依赖关系。 - 在一个容器化的环境中，在Dockerfile中执行此操作。注意：我们建议您在全面的基础架构即代码策略背景下选择依赖管理机制，而不是作为单独的决策。

3 - 配置

在环境中存储配置

任何部署之间的差异都可以视为配置。Twelve-Factor App指南建议将所有配置存储在环境中，而不是将其提交到存储库。我们推荐以下具体做法：

使用非版本控制的.env文件进行本地开发。Docker支持在运行时加载这些文件。
将所有.env文件保存在一个安全的存储系统（如Vault）中，以使这些文件可供开发团队使用，但不会提交给Git。
对运行时可能更改的任何内容以及不应提交给共享存储库的任何内容使用环境变量。
将应用程序部署到交付平台后，使用交付平台的机制来管理环境变量。

4 - 支持服务

把后端服务当作附加资源

Twelve-Factor App指南将支持服务定义为“作为其正常操作的一部分，应用程序在网络上使用的任何服务”。微服务的含义是服务外部的任何内容都被视为附加资源，包括其他服务。这确保了每个服务都是完全可移植的，并且松散地耦合到系统中的其他资源。此外，严格的分离会在开发过程中提高灵活性 - 开发人员只需运行他们正在修改的服务，而不需要运行其他服务。

5 - 构建，发布，运行

严格分离构建和运行

为了支持严格分离构建，发布和运行阶段，我们推荐使用持续集成/持续交付（CI / CD）工具来自动构建。Docker镜像可以轻松分离构建和运行阶段。理想情况下，镜像是从每次提交创建的，并被视为部署工件。

6 - 过程

以一个或多个无状态进程运行应用

对于微服务，进程因素中的重要一点是您的应用程序需要无状态。这可以通过简单地添加更多的服务实例来轻松扩展服务。将任何有状态数据或需要在实例之间共享的数据存储在后备服务中。

7 - 数据隔离

通过端口绑定提供服务

作为使端口绑定因子对微服务更有用的修改，建议只允许通过服务的API访问服务拥有的持久数据。这可以防止微服务之间的隐式服务契约，并确保微服务不能紧密耦合。数据隔离还允许开发人员为每项服务选择最适合其需求的数据存储类型。

8 - 并发性

通过进程模型进行扩展

Unix进程模型在很大程度上是微服务架构的一个前辈，因为它允许在单个应用程序中对不同任务进行特例化和资源共享。在微服务体系结构中，您可以独立地水平扩展每项服务，并在底层基础结构支持的范围内。使用集装箱化服务，您可以免费获得Twelve-Factor应用程序推荐的并发性。

9 - 可丢弃性

快速启动和优雅终止可最大化健壮性

服务实例需要一次性使用，以便可以快速启动，停止和重新部署，并且不会丢失数据。部署在Docker容器中的服务会自动满足此要求，因为它是容器的固有功能，可以立即停止并启动它们。将状态或会话数据存储在队列或其他后备服务中可确保在发生容器崩溃时无缝处理请求。

10 - 开发/产品奇偶校验

尽可能的保持开发，预发布，线上环境相同

尽可能保持所有的环境 - 开发，阶段，生产等 - 以减少只在某些环境中出现错误的风险。为了支持这个原则，我们再次推荐使用容器 - 这里是一个非常强大的工具，因为它们使您能够从本地开发到生产全过程运行完全相同的执行环境。但请记住，底层数据的差异仍然会在运行时造成差异。

11 - 日志

把日志当作事件流

不要在微服务中包含用于路由或存储日志的代码，而要使用市场上许多优秀的日志管理解决方案之一，其中几个列于十二因子应用程序中。此外，决定如何使用日志需要成为更大的APM和/或PaaS策略的一部分。

12 - 管理进程

后台管理任务当作一次性进程运行

在生产环境中，与应用程序分开运行管理和维护任务。容器使得这很容易，因为你可以启动一个容器来运行一个任务，然后关闭它。