服务架构演进小结
系统架构的演进大致可分为“单体”和“微服务”两个阶段，其中，根据基础设施能力下沉程度的不同，微服务架构又可以细分为“微服务”和“云原生两个阶段，后者以 Kubernetes 为基础。另外，“无服务”架构正在受到越来越多的关注。无服务与微服务并没有继承或替代的关系，目前，无服务的云函数可以作为部分微服务的一种实现方式。在未来的云计算中，无服务会有更广阔的空间。
《凤凰架构》一书提供了 Fenix BookStore 这个 Java 演示项目，通过不同架构的版本对服务架构演进的各个阶段做了具体的介绍，以下结合该项目总结了关于架构演进的一些理解。
单体架构：Spring Boot
演示项目：https://github.com/fenixsoft/monolithic_arch_springboot，基于 Spring Boot。
单体架构本身不需要多说，这里值得一提的是“领域驱动设计”（Domain-Drive Design）这种软件设计方法。在业务逻辑比较复杂的软件系统中，该方法可以对系统进行解耦，使子模块的职责清晰。并且在微服务架构中，DDD 也可以指导对服务的拆分。在 Fenix BookStore 项目中，系统被划分为“用户”、“商品”与“支付”三个业务模块。
除了横向地按业务划分不同的模块，DDD 还纵向地对系统进行分层，解耦业务逻辑与技术实现。通常，DDD 采用下面的四层架构。
User Interface：提供用户交互接口，比如 RESTful API。
Application：暴露软件对外的能力，可以理解为通过向下调用各个模块的方法共同提供某项具体能力，比如支付账单需要涉及订单状态变更、账户资金扣减、商品库存扣减、商品状态变更等不同模块的多个动作。因此，该层通常成为包裹事务的载体。
Domain：包含领域内的核心业务规则，比如前面提到的账户资金扣减这类具体的业务逻辑。
Infrastructure：基础设施层，向其它层提供通用的技术能力，比如持久化能力、基础工具集等。
微服务：Spring Cloud
演示项目：https://github.com/fenixsoft/microservice_arch_springcloud，基于 Spring Cloud。
随着业务的发展，系统变得越来越庞大，自然会想到对系统进行拆分。其中的理由包括：
通过物理隔离阻断故障传播，避免某一模块影响整体系统；
允许技术异构，充分利用各个不同生态的能力；
灵活运维，某一模块升级不要求系统整体停机。
系统拆分成不同的服务之后，就成为了分布式的系统，因而会面临新的问题，包括但不限于：
服务发现，某个服务上线后其它服务如何知道它在哪里；
服务间通信，比如不同内存格式的数据如何共享，网络问题如何解决；
配置管理，不同服务可能共用某些配置，该配置发生变更时若需要手动修改所有相关服务的配置会很麻烦；
API 网关（API Gateway），微服务架构下，客户端需要有一个统一的访问入口，该入口负责处理请求并将其路由到对应的后端服务；
数据一致性，一个事务可能涉及多个服务的数据变更，如何保证事务能被正确的提交和回滚；
可观测性，如何追踪跨服务的请求链路。
Spring Cloud 框架基于 Java 生态提供了丰富的组件，能够解决其中的部分问题，但都需要在应用中添加额外的代码逻辑来集成相关的组件，这对应用开发者很不友好，增添了许多额外的负担。究其原因，是因为 Spring Boot 本质上是一个应用开发框架，因而不得不嵌入很多业务无关的基础设施逻辑。因此，我们自然会想将这些基础设施能力从应用中剥离出去。而 Kubernetes 能够做到。
微服务：Kubernetes
演示项目：
Kubernetes 作为一个基础设施底座，提供了通用的基础能力，进一步封装成 Paas 平台后，业务开发就无需再关心原有的大部分非业务逻辑，应用部署也变得很简单。比如，Kubernetes 通过 Service 来管理服务，支持了服务发现和负载均衡；Kubernetes 通过 ConfigMap、Secret 实现了配置管理。此外，Kubernetes 还提供了丰富的自动化运维能力。
不过，虽然 Kubernetes 已经很强大了，但 Kubernetes 本身还无法支持精细化的服务管理，比如熔断、流量控制等。于是，基于 Kubernetes 的服务网格出现了。服务网格通过一个与主应用容器并行运行的辅助容器（Sidecar）来拦截和管理服务间的所有网络通信，进一步将流量控制、安全、可观测性等能力下沉到了基础设施层。这使得在使用 Istio 服务网格版本的 Fenix BookStore 中，所有 Spring Cloud 中的技术组件全部被移除。Kubernetes 和服务网格基本使得业务和非业务的基础技术完全分离。
未来，Kubernetes 将会成为服务器端标准的运行环境，如同现在的 Linux 系统；服务网格将会成为微服务之间通信交互的主流模式。
无服务
无服务（Serverless）与前面的单体、微服务架构没有逻辑上的继承或者替代关系，当前，可以理解为 Serverless 是一种新的服务形态。与传统的长时间常态运行的服务不同，Serverless 服务通常是事件驱动的，因此基本不需要做资源规划，可以用多少付多少。Serverless 服务也称为函数（Function），提供相关服务管理能力的 Pass 平台也称为 Faas 平台，如火山引擎的 veFaaS [2]。
作者周志明老师对无服务未来的发展持谨慎乐观的态度，认为其长期的远景是美好的，但如果日后没有重大变革的话，很难成为一种普适性的架构模式。
参考资料
《凤凰架构》