原文发布在 InfoQ
尽管微服务架构长期以来被视为云原生应用的事实标准，但在 2023 这一年，来自各方的反思声音逐渐增多。去年 3 月，AWS 分享了一个案例，Prime Video 团队将其 Serverless 应用程序中的部分微服务调整成为了一个单体，称此举节省了 90% 的运营成本。 DHH 对此评论道：“亚马逊也无法理解无服务器或微服务。”谷歌也于去年开源了一个名叫 Service Weaver 的框架，在相关论文中，他们表示这种方法可以将发布式系统带来的延迟降低 15 倍，成本降低 9 倍。
那么，微服务到底有没有什么问题？Service Weaver 是否能够成为微服务架构的“新解”呢？
微服务架构今年已经满十岁了，它的演进关键阶段如何？目前分布式架构还面临的最大挑战是什么？
微服务架构在过去十年中经历了几个关键阶段的演进：
- 初期探索阶段（2010-2013 年）：
- 微服务概念的提出和初步探索，尝试将传统的单体应用拆分成小型、自治的服务。
- 技术领域开始出现一些支持微服务架构的工具和平台，但尚未形成成熟的最佳实践。
- 早期采用和成熟化（2014-2016 年）：
- 微服务架构得到更广泛的关注和采用，许多组织开始将其应用于生产环境中。
- 持续集成和持续交付（CI/CD）、容器化技术（如 Docker）、编排工具（如 Kubernetes）的出现和广泛应用，为微服务的部署和管理提供了更多支持。
- 成熟阶段和生态系统建设（2017- 至今）：
- 微服务架构成为主流，许多大型企业和组织开始采用，并建立了成熟的最佳实践和模式。
- 服务网格（Service Mesh）的兴起，为微服务架构中的服务通信、可观测性和服务治理提供了更多的解决方案。
- 基于云原生和 Serverless 的发展，微服务架构更趋向于弹性、自动化和灵活性。
微服务架构的一些挑战包括：
- 微服务拆分与粒度：微服务粒度的控制对整个架构的性能、可维护性和扩展性都有很大的影响。微服务粒度的控制是一个动态的且充满挑战的事情。
- 微服务需要治理：随着服务数量的增加，需要解决服务发现、负载均衡、版本控制等问题，确保服务之间的通信可靠性和一致性。
- 分布式系统复杂性管理：微服务架构涉及多个分布式组件，因此需要处理分布式系统带来的复杂性，如一致性、事务管理和错误处理。
- 安全性需求变高：分布式系统面临着更多的安全挑战，需要确保每个服务都能得到充分的保护，防止安全漏洞和攻击。
- 文化和组织变革：采用微服务架构需要组织文化的变革，包括团队间的协作、持续交付和 DevOps 文化的推广。
解决这些挑战需要不断演进的工具、最佳实践的制定以及组织文化上的变革，以确保微服务架构能够持续发展、能在复杂的环境中稳定运行以及获得真实的收益。
2023 这一年架构领域有哪些关键框架 / 组件有关键更新或演进？
架构领域一直在不断演进和更新，在 2023 年，一些关键框架和组件经历了重要的更新或者取得了进展：
服务网格：更加成熟的实现和标准化。继 Proxyless Mesh，Istio 今年推出 Ambient Mesh 模式，并正式从 CNCF 毕业，成为 CNCF 活跃度排名第三的项目。
开发框架：更多适用生产环境微服务架构的开发框架。以 Kitex/Hertz 为例的微服务框架更加关注企业用户在生产环境的落地和使用反馈，关注易用性和降本增效成为框架选型的主流意见。
编程语言与生态：Golang 成为国内诸多大厂主流或最热门的编程语言，Golang 相关的开源中间件生态繁荣，竞争加剧；Rust 成为最有潜力的编程语言，诸多大厂纷纷投资入局，新的 Rust 微服务框架如 Volo 推动 Rust 在企业内部更广泛落地。
字节跳动服务框架团队联合 CloudWeGo 开源社区发布 《CloudWeGo 技术白皮书: 字节跳动云原生微服务架构原理与开源实践》助力企业用户完成微服务架构转型，实现降本增效和稳定性提升。
微服务、单体、模块：解决过度复杂性和缺乏可维护性的方法是“模块化”吗？
“模块化”确实是解决复杂性和可维护性问题的一种重要方法，但并不是唯一的方法。微服务架构、单体应用和模块化都可以在一定程度上解决复杂性和可维护性问题，但它们有不同的特点和适用场景。
模块化指的是将一个系统或应用拆分成独立的功能模块，每个模块都有明确定义的职责和界限。模块化可以促进代码重用，减少重复编写相似功能的代码；模块化降低了系统的耦合度，使得单个模块的修改和维护更加简单和安全。但是，如果模块之间的交互设计不合理，或者模块划分不够清晰，仍然可能导致系统的复杂性和维护困难。模块化架构在服务弹性和可靠性仍存在挑战。
微服务架构和单体应用则是针对不同需求和场景的解决方案。微服务架构通过将应用拆分成小的、自治的服务来解决单体应用的复杂性和可维护性问题。而单体应用虽然有着较高的集中性和一体性，但在一些规模较小或者业务简单的情况下，也能够提供良好的开发和维护体验。
在解决复杂性和可维护性的问题时，并非只有一种方法是完全正确的。模块化是一个重要的思维模式和架构方法之一，但结合实际需求和场景，可能需要综合考虑模块化、微服务架构、单体应用等不同的解决方案。
在大型企业中，采用微服务架构后，随着业务的快速增长，出现微服务过微或者过度复杂似乎是一件不可避免的事情。这个时候，企业需要一套成熟的微服务架构复杂度治理体系，用来管控增量服务和治理存量服务。 字节跳动于 2023 年正式启动微服务架构复杂度治理，大致分为服务数治理、依赖治理和领域治理，循序渐进，依次治理，逐步深入。以服务治理为例，既包括对功能废弃服务、过微服务、长尾服务、定位重复服务等存量服务的下线治理，也包含合理的增量管控策略。而链路治理和领域治理则是围绕优化架构反模式和面向领域的微服务架构治理展开。
如何看待 Google 发布的 Service Weaver，是否代表未来一种主流解决方案？
Service Weaver 提供了一个灵活的框架，能够在本地简化开发，并将模块化单体应用转变为分布式微服务架构，在部署时允许自由配置组件的分布式部署方式，从而应对应用演进过程中的不确定性，并轻松适应组件间交互模式的变化。
可以看到，Service Weaver 提供了一种全新的开发与部署解决方案，其最大的特点就是提供了一种灵活性和可配置性，对于业务的演进非常友好，可以灵活调整部署模式，来实现成本优化和价值最大化。
但是，Service Weaver 目前仍处于早期开发阶段，可能存在稳定性和功能性方面的限制。这意味着可能会有一些尚未解决的问题，或者缺少一些重要的功能，因此尚不适合在生产环境中落地，后续有待于观望，包括更广泛的采纳和活跃的社区支持。其次，也是最重要的一点，这种架构模式并不适应于已经落地了微服务架构的业务，也不适应于已经比较稳定的业务，更不适应于对于性能要求极高的业务。反过来说，Service Weaver 对于尚处于快速发展的互联网在线业务比较友好，允许应用程序随着时间的推移进行低成本演进。
与 Service Weaver 架构模式相对应的，字节跳动正在内部大规模落地合并部署与合并编译，这是给已经大规模落地微服务架构的业务提供一种降本增效的手段。合并部署方案主要思路是结合容器亲和性调度、流量调度计算、更高效的本地通信，让原本需要跨机的网络通信变成同机进程间调用，既能与现有体系融合又能减少微服务链路带来的性能损耗。
合并编译则是一套全新的微服务编排思路，还是基于微服务的模式开发，在编译 / 发布期像内联函数一样内联微服务，以实现微服务成本优化。既可以拥有单体的性能，又拥有微服务的研发效率。其核心目标是将微服务进程间通信开销变成进程内方法调用，避免网络传输和序列化成本，也无需微服务治理逻辑以及其带来的一切成本开销。
合并编译方案已在字节跳动内部多个业务线中使用，接入核心超过百万核，在不影响研发效率的情况下，带来数十万核的性能收益。在将于 2024 年 4 月 18-20 日举办的 QCon 全球软件开发大会（北京站）2024 的「单体 vs 微服务」专场，字节跳动服务框架团队研发工程师尹旭然将以 《大规模微服务破局之道：合并编译》 为题，把方案落地经验分享出来。
云原生可移植性设计比如 Dapr 等框架是否有得到广泛采用？
Dapr 作为新兴的云原生项目，以"应用运行时"之名围绕云原生应用的各种分布式需求，致力于打造一个通用且可移植的抽象能力层。这个愿景有着令人向往的美好前景，然而 API 的标准化之路异常艰辛，Dapr 的分布式能力抽象在实践和落地过程中遇到了各种挑战和困扰。据观察，Dapr 近年来得到了不少关注，但是在国内并没有得到广泛的采用。
与服务网格相比，Dapr 架构更加复杂，Dapr 的工作模式是能力抽象，需要业务应用程序遵从标准 API 进行请求开发与改造。服务网格主要设计目标是低侵入，采用原协议转发的方式可以尽可能的降低对应用的侵入。Dapr 的主要设计目标是可移植性，即在跨云跨平台的前提下实现无厂商绑定，采用的方式是在将分布式能力抽象为标准 API，并在各种开源项目和云平台上提供这套标准 API 的不同实现，从而达到在不同平台上运行的目标。因此 Dapr 的代价是需要应用进行适配和改造，侵入性比较大。因此 Dapr 更适合新应用开发 （Green Field），对于现有的老应用（Brown Field）则需要付出较高的改造代价。这也是 Dapr 当前并未获得广泛采用的主要原因。
虽然 Dapr 和类似的框架提供了许多优势和新颖的特性，未来仍需要更多时间、成熟度和社区的支持。在面对已有系统、组织惯例和技术选型方面，新框架的采用需要认真权衡其优势与现有解决方案的差异，并选择最适合的方案。
架构设计文化还发生了哪些变化？有哪些在消亡，有哪些得到演化？
根据本人经验和观察，近年来，软件架构设计文化经历了一些显著的变化：
- 演进的设计方法论：架构设计不再仅限于传统的 UML 或架构描述语言。更多的方法和实践在不同领域兴起，如面向领域的设计（DDD）等，强调交互式和迭代式设计过程。
- 微服务成熟和治理：微服务架构已经不再是新兴概念，而是被广泛接受并应用。焦点已经从单纯的微服务拆分转移到了治理、监控、自动化和安全等方面。多样的架构模式以及眼花缭乱的微服务框架为架构师的技术设计与选型同样带来挑战。
- 云原生和容器化：云原生设计和容器化技术对架构设计产生了深远影响。设计需要更多地考虑弹性、可扩展性和云端部署的优化。
技能要求的转变主要包括，需要深入了解云原生编排、容器化、服务网格、微服务框架、CICD、可观测等诸多技术，以便为应用程序选择最佳的部署和运行环境、提供安全能力和微服务治理能力、保障系统的稳定性和可靠性。
人工智能会对软件架构以及架构设计的哪些方面造成影响？
2023 年，人工智能（AI）展现了前所未有的智慧和发展，尤其是在基础大模型领域，给很多人带来了很多机遇和挑战。与此同时，AI 原生应用的发展尚处于早期，AI 对于软件架构与设计的影响尚没有在大规模生产环境下得以体现和验证，但是不可否认的是，AI 必然可以带来多维度的变化。 比如，AI 可以帮助提高决策效率、优化设计、增强系统的自适应性和安全性，以及更好地应对系统的演化和变化。然而，AI 技术在这方面的应用也需要考虑隐私、安全以及技术成熟度等方面的问题。
展望下架构未来 3-5 年的发展
预料一下几点：
持续的云原生和微服务发展：云原生和微服务架构会继续发展并成为主流，更多企业将采用这些架构以获得更好的弹性、扩展性和敏捷性。尤其是传统行业，其云原生架构采纳和转型还处于非常早期，需要诸多微服务基础设施和通用能力来简化云原生改造成本。
AI 在架构中的应用增加：AI 技术将更广泛地用于架构设计中，包括 AI 辅助设计、决策支持与建议、智能监控、性能优化等方面，提高架构设计和系统优化的智能化水平。
低代码 / 无代码平台的普及：随着 AI 能力的支持与落地，低代码 / 无代码平台将得到更广泛的应用，使得开发人员能够更快速地开发、构建和部署应用，对架构设计也会带来一定的影响。