那么，微服务到底有没有什么问题？ServiceWeaver是否能够成为微服务架构的“新解”呢？在年终盘点之际，InfoQ采访了字节跳动服务框架团队架构师、CloudWeGo开源负责人罗广明，探讨了微服务发展十几年来的进展和关键技术演变。
InfoQ：微服务架构今年已经满十岁了，您是否能总结下它的演进关键阶段？目前分布式架构还面临的最大挑战是什么？
罗广明：微服务架构在过去十年中经历了几个关键阶段的演进：
微服务架构的一些挑战包括
解决这些挑战需要不断演进的工具、最佳实践的制定以及组织文化上的变革，以确保微服务架构能够持续发展、能在复杂的环境中稳定运行以及获得真实的收益。
InfoQ：这一年架构领域有哪些关键框架/组件有关键更新或演进？
罗广明：架构领域一直在不断演进和更新，在2023年，一些关键框架和组件经历了重要的更新或者取得了进展：
InfoQ：微服务、单体、模块：有人认为决过度复杂性和缺乏可维护性的方法是“模块化”，您同意这个观点吗，为什么？
罗广明：“模块化”确实是解决复杂性和可维护性问题的一种重要方法，但并不是唯一的方法。微服务架构、单体应用和模块化都可以在一定程度上解决复杂性和可维护性问题，但它们有不同的特点和适用场景。
模块化指的是将一个系统或应用拆分成独立的功能模块，每个模块都有明确定义的职责和界限。模块化可以促进代码重用，减少重复编写相似功能的代码；模块化降低了系统的耦合度，使得单个模块的修改和维护更加简单和安全。但是，如果模块之间的交互设计不合理，或者模块划分不够清晰，仍然可能导致系统的复杂性和维护困难。模块化架构在服务弹性和可靠性仍存在挑战。
微服务架构和单体应用则是针对不同需求和场景的解决方案。微服务架构通过将应用拆分成小的、自治的服务来解决单体应用的复杂性和可维护性问题。而单体应用虽然有着较高的集中性和一体性，但在一些规模较小或者业务简单的情况下，也能够提供良好的开发和维护体验。
在解决复杂性和可维护性的问题时，并非只有一种方法是完全正确的。模块化是一个重要的思维模式和架构方法之一，但结合实际需求和场景，可能需要综合考虑模块化、微服务架构、单体应用等不同的解决方案。
在大型企业中，采用微服务架构后，随着业务的快速增长，出现微服务过微或者过度复杂似乎是一件不可避免的事情。这个时候，企业需要一套成熟的微服务架构复杂度治理体系，用来管控增量服务和治理存量服务。字节跳动于2023年正式启动微服务架构复杂度治理，大致分为服务数治理、依赖治理和领域治理，循序渐进，依次治理，逐步深入。以服务治理为例，既包括对功能废弃服务、过微服务、长尾服务、定位重复服务等存量服务的下线治理，也包含合理的增量管控策略。而链路治理和领域治理则是围绕优化架构反模式和面向领域的微服务架构治理展开。
InfoQ：今年一个比较大的事件是Google发布了ServiceWeaver，允许用户“将应用程序编写为模块化整体，并将其部署为一组微服务”，这种方法有可能代表未来的一种相对主流解决方案吗？
罗广明：ServiceWeaver提供了一个灵活的框架，能够在本地简化开发，并将模块化单体应用转变为分布式微服务架构，在部署时允许自由配置组件的分布式部署方式，从而应对应用演进过程中的不确定性，并轻松适应组件间交互模式的变化。
可以看到，ServiceWeaver提供了一种全新的开发与部署解决方案，其最大的特点就是提供了一种灵活性和可配置性，对于业务的演进非常友好，可以灵活调整部署模式，来实现成本优化和价值最大化。
与ServiceWeaver架构模式相对应的，字节跳动正在内部大规模落地合并部署与合并编译，这是给已经大规模落地微服务架构的业务提供一种降本增效的手段。合并部署方案主要思路是结合容器亲和性调度、流量调度计算、更高效的本地通信，让原本需要跨机的网络通信变成同机进程间调用，既能与现有体系融合又能减少微服务链路带来的性能损耗。
合并编译则是一套全新的微服务编排思路，还是基于微服务的模式开发，在编译/发布期像内联函数一样内联微服务，以实现微服务成本优化。既可以拥有单体的性能，又拥有微服务的研发效率。其核心目标是将微服务进程间通信开销变成进程内方法调用，避免网络传输和序列化成本，也无需微服务治理逻辑以及其带来的一切成本开销。
InfoQ：云原生可移植性设计比如Dapr等框架是否有得到广泛采用？为什么？
与服务网格相比，Dapr架构更加复杂，Dapr的工作模式是能力抽象，需要业务应用程序遵从标准API进行请求开发与改造。服务网格主要设计目标是低侵入，采用原协议转发的方式可以尽可能的降低对应用的侵入。Dapr的主要设计目标是可移植性，即在跨云跨平台的前提下实现无厂商绑定，采用的方式是在将分布式能力抽象为标准API，并在各种开源项目和云平台上提供这套标准API的不同实现，从而达到在不同平台上运行的目标。因此Dapr的代价是需要应用进行适配和改造，侵入性比较大。因此Dapr更适合新应用开发（GreenField），对于现有的老应用（BrownField）则需要付出较高的改造代价。这也是Dapr当前并未获得广泛采用的主要原因。
InfoQ：微服务兴起后，架构领域有了一个变革：架构更多的是做出设计决策，而不是使用UML或架构描述语言绘制方框和线条。最近这十年，您观察到架构设计文化还发生了哪些变化？有哪些在消亡，有哪些得到演化？软件架构师的技能要求主要有哪些改变？
罗广明：根据本人经验和观察，近年来，软件架构设计文化经历了一些显著的变化：
技能要求的转变主要包括，需要深入了解云原生编排、容器化、服务网格、微服务框架、CICD、可观测等诸多技术，以便为应用程序选择最佳的部署和运行环境、提供安全能力和微服务治理能力、保障系统的稳定性和可靠性。
InfoQ：您认为人工智能会对软件架构以及架构设计的哪些方面造成影响？
罗广明：2023年，人工智能（AI）展现了前所未有的智慧和发展，尤其是在基础大模型领域，给很多人带来了很多机遇和挑战。与此同时，AI原生应用的发展尚处于早期，AI对于软件架构与设计的影响尚没有在大规模生产环境下得以体现和验证，但是不可否认的是，AI必然可以带来多维度的变化。比如，AI可以帮助提高决策效率、优化设计、增强系统的自适应性和安全性，以及更好地应对系统的演化和变化。然而，AI技术在这方面的应用也需要考虑隐私、安全以及技术成熟度等方面的问题。
InfoQ：您能展望下架构未来3-5年的发展吗？
罗广明：这个问题太庞大了，可以简单预料一下几点：
持续的云原生和微服务发展：云原生和微服务架构会继续发展并成为主流，更多企业将采用这些架构以获得更好的弹性、扩展性和敏捷性。尤其是传统行业，其云原生架构采纳和转型还处于非常早期，需要诸多微服务基础设施和通用能力来简化云原生改造成本。
AI在架构中的应用增加：AI技术将更广泛地用于架构设计中，包括AI辅助设计、决策支持与建议、智能监控、性能优化等方面，提高架构设计和系统优化的智能化水平。
低代码/无代码平台的普及：随着AI能力的支持与落地，低代码/无代码平台将得到更广泛的应用，使得开发人员能够更快速地开发、构建和部署应用，对架构设计也会带来一定的影响。
在2023年结束之际，InfoQ编辑部重磅推出“年度技术盘点与展望”专题，聚焦AIGC引发的变革，与50多位头部专家深度对话，希望能为你揭示架构、前端、运维、大数据、云计算、编程语言、数据库等领域的核心变化和演进逻辑，明晰金融、汽车、制造、零售等行业的数字化、大模型应用思路和路径。