如何更好地干掉微服务架构复杂性？

分而治之是面对复杂问题时的惯用方法，微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践。但是过去几年，无数的中小团队在微服务上陷入了挣扎，很多公司在放弃微服务，其中包括一些大型企业，比如 2020 年，Uber 放弃了微服务，转而使用宏服务；GitHub 的前 CTO 近期也表示全面微服务是最大的架构错误，这其中不乏对引入微服务架构带来的复杂性的声讨。那么，微服务架构带来的复杂性和架构问题到底如何被干掉呢？

本期《极客有约》，我们邀请到了快手微服务中间件技术负责人魏诗白，去哪儿旅行技术总监、技术委员会委员郑吉敏和网易数帆云原生技术专家、架构师裴斐一同探讨云原生时代，微服务架构治理之道。

如何降低微服务架构复杂度？

InfoQ 第一问：大家有遇到哪些不适合用微服务架构，但却用了微服务架构的案例？

裴斐：主要有两大类，第一类比较常见，比如一些架构复杂性并不高的小型业务系统，这类系统使用传统的单体架构足以支撑，引入微服务架构反而会给研发团队带来很多复杂度和不确定性，进而导致不必要的成本损耗。

第二类是底层基础平台，典型的例子就是早期的 Istio。Istio 作为开源服务网格框架，其自身也采用了微服务架构，包括微服务的组件 Pilot、Mixer、Citadel 等。这样设计的初衷是希望系统可以按照基础能力更好地分层和配合，同时提供更好的能力抽象。弊端是这也成为了 Istio 早期的“阿喀琉斯之踵”，比如其以 Mixer 作为后端微服务，服务间互访时候均会调用 Mixer 同步 Check，这就成为整个微服务系统的性能瓶颈。Istio 1.5 版本从微服务架构回归到单体架构，重新走上了代表服务网格发展的正道。

魏诗白：以快手的实际业务架构为例，早期内部有一个大型服务本身采用的是微服务架构，但是随着业务迭代，其变得越来越复杂，于是业务架构师们就决策要不要做进一步拆分。

这个过程出现过很多反例，一是在实践过程中发现有些业务的依赖较重，比如依赖很重的缓存，这可能影响服务本身的稳定性。为了解决该问题，我们将缓存相关逻辑打包成接口，并且服务化掉，看似通过物理隔离的方式解决了问题，但这对后续的维护包括资源占用都起到了反作用，真正解决这个问题应该从架构本身来看缓存设计是否合理。

二是有些业务开发人员服务拆分经验较少且有一些工程师心理，写新 Feature 时经常会找不到合理的、可实现的位置安放，于是就会想一些比较 Trick 的方式，比如写一个 For Side Service，然后把相关逻辑包装成微服务上线。他们没有考虑业务本身的依赖逻辑关系，而是单纯为了实现一个服务去实现一个服务，这也是一个比较明确的反例。

郑吉敏：我来自去哪儿旅行，主要负责酒业相关业务。在酒业搜索做召回时，用户搜索指定日期会看到很多酒店，其内有对排序很重要的因子，就是这些酒店是否在条件里——是否有房态。假如酒店没房，排序会特别置底。

为了做好这件事情，我们需要投入很多精力解决两个核心问题：一是去哪儿网本身没有库存，资源完全来自于供应链，因此需要快速计算当前哪些酒店有库存。

二是排序对性能要求特别高，旧版解决方案是在路由层面配置了 86 个有状态的集群，请求进来会哈希到 86 个集群上面，这样可以解决一些问题，比如正常情况下，在线酒店的日期组合是 80 多万，结合日期差级是一个特别大的数量级，这是无法存储下来的，但是为了保证性能，可以用到 86 个集群的内存。这也会带来一些问题，比如每次请求都要先哈希到对应集群，再继续看内存里面是否有库存。如果有，直接返回有库存。如果没有，第一次返回无库存，之后做异步探测，将库存写到内存里，第二次就可以返回有库存。

这个设计短期内解决了一些问题，但我发现其中有两个特别严重的问题。第一，每天哈希之后的结果是不同的，导致 86 个集群每天都有个别出现问题，但是又无法修正，相当于每次都会有请求受影响；第二，有些场景扩展特别难，这是我遇到最痛苦的不适合微服务但是用了的场景。为了对此做支持，团队花费了很大精力，开发用了九个月的时间才把整个事情收尾。核心在于，我们因为微服务搞出来的一些有状态的事情很不适合微服务架构，同时我们要解决的问题更多偏向扩展性，不太适合微服务架构。

InfoQ 第二问：微服务架构的复杂性具体体现在哪几个关键的层面？各自在公司的实践过程中踩过哪些坑？

魏诗白：以我个人的实践经验为例。一方面，微服务架构本身肯定需要额外的基础能力，比如需要做服务治理，本来的单体应用扩散到分布式可能需要服务本身的配置管理以及相关链路级别的监控、Tracing 能力，公司层面可能需要组织一个团队搭一套微服务解决方案，这些对底层架构、工程师经验、运维都提出了很高要求。

另一方面是业务层面，以一个 Java 生态栈为例，很可能出现 jar 包依赖版本管理问题，这是比较严重的，经常会有一些由于版本依赖管理不合理导致编译冲突、上线的 Runtime Error 这种问题，一般都会影响整个研发和 CI/CD 效率。这就体现出业务之间如何做服务治理，包括合理的业务资源架构领域解耦等。

即便是现有的开源方案同样无法完全自动化运维，肯定需要具备相关经验的架构师参与进来解决问题，尤其是随着公司本身的业务迭代速度，包括业务体量增长，对分布式架构包括分布式组件、中间件的要求会越来越复杂，很多能力是开源组件无法提供的，这就需要提供各种需求支撑业务发展，需要越来越庞大的团队去支撑，这也是我们团队现在面临的主要问题之一。

裴斐：我大概总结了三个关键词，分别是引入、异构、冗余。

1.引入。我们在引入微服务架构之后，必然会出现新的问题，比如服务网格本质上也是为了解决一些传统微服务架构存在的升级难或者侵入性大等问题，但是同时服务网格的引入也带来了一些新的问题，比如 Sidecar Proxy 带来了更多的延迟和性能的损耗。

2.异构。对业务来说，服务架构并不是天生统一的，一方面是业务中同时存在多种异构系统，比如有的业务会采购一些系统，彼此之间采用的开发语言、协议等可能都不一样，不同异构系统之间非常难做到真正意义上的打通和统一管理。另外一方面是业务系统本身如何保障新老架构的平滑演进，在这个过程里面对于业务尽量无感知或者少感知。

3.冗余。冗余就是业务迁移到新架构中可能会出现的问题，比如老技术组件的冗余。早年，非常多业务普遍在生产上使用 Nginx 这样的流量代理软件，后来随着微服务架构的兴起，业务往往会引入一个新的组件——微服务 API 网关。但从流量处理能力上 Nginx 与 API 网关存在重叠，这就使得很多微服务架构一上手就在架构边缘有冗余，要解决组件重叠带来的延时、资源损耗以及维护性变差等等问题。。

郑吉敏：微服务确实对整个公司的基础研发要求特别高，比如正常的服务治理、协议转换、网络时延是否能用；需要开几个新的微服务；链路治理，查问题特别依赖基础组件本身的完善性，那么外部组件是否能满足要求。很多时候，当我们真的引入那些组件时，需要基于它们做二次开发，来满足公司定制方面的东西，这很考验整个技术研发能力。

我们在做微服务时，除了要站在技术角度，还要站在业务角度。比如微服务究竟怎么划分是个特别关键的问题，并不是说有了技术能力支持，就可以找到一个标准去开启新的微服务。究竟怎么划分能更好地支撑业务发展，尤其是支撑未来的业务扩展，这些都非常关键。

而且这个过程中如果出现不合理的情况，治理压力会更大，比如遗留服务。遗留服务很多时候来源于前期的设计不合理，以及当前的设计很难满足未来需求，这方面如果考虑的少也是很大的问题。因此，我认为微服务要兼顾当前整个公司的基础水平以及业务发展的需要，两者结合才能真正做好。

InfoQ 第三问：针对如何更好地去干掉微服务架构复杂性，有哪些解决思路？

郑吉敏：首先回归事情的本质，我上述所言的业务逻辑本质是确定房态，房态是搜索因子，正常情况下应该放在搜索团队内部。我们换一种方式，取一些稍微粗略的落地数据通过一个流程写入搜索内存，相当于多耗一点内存就可以将路由层的 86 个集群全部干掉。这里面过程比较复杂，花费的时间比较长，因为要把整个链路走通，包括把全量和增量拉齐以及数据变更如何快速通知到位。

核心在于大家要先明确服务到底应该做什么事情，要解决的本质问题是什么以及属于哪个领域内的问题，并把这些问题交给对应方解决而不是引入一个微服务去解决。

除了解决单点问题，我们对内部架构也做了特殊治理，我们把内部团队划分成几个比较大的领域，比如供应链域、核心领域、网关域。一个请求进来之后会通过网关域组装下面的核心领域，核心领域依赖供应链，供应链跟外部交互，网关相当于接收的是从自己 APP 过来的请求去组装中间的核心领域。核心领域包含搜索域、报价域、营销域以及订单域，通过域把每个团队资源的核心服务分开，报价域内部可能还分定价相关的模块，营销域分商家促销、平台促销以及补贴方面的事情。基于此，每个核心域还会把自己内部的模块进行划分。

我们从全局视角知道模块划分原则以及每个模块的具体职责。比如营销域的一个商促通常会划分成三个模块：实时运算，数据同步，数据模型转换。这样，每个模块做的核心事情比较明确，结合在一起就可以构成一个微服务组一起提供商促服务。当需要扩展时，我们只要在对应的微服务进行扩展就可以，接入也比较快。这是我受益最大的地方，相当于是先将团队按照一定领域划分，团队内部负责的领域再拆分出多个核心模块。

裴斐：主要有三方面：一是如何解决新架构引入的新问题。举例来说，比如服务网格引入了 Sidecar Proxy，带来了更多延时损耗，从引入服务网格到业务之后一直做的事情是加速。最初我们针对性地做了一些网格加速能力的构建，目前也有一些沉淀，我们会配合网易云底层的网络团队、SR-IOV、用户态协议栈等偏重于优化底层网络、容器网络的技术，一起优化服务之间通过 Sidecar 的网络延时。

去年至今比较火的概念是 Proxyless。既然 Proxy 的方式带来了很多问题，就需要尝试把 Proxy “less” 化，相当于无 Proxy。有非常多的企业都在关注这方面，尤其是大的互联网企业，都有自己的 Proxyless 技术路线。

我们在做的两条路线：一条路线是基于 Java 的无侵入 Agent，在应用进程内实现 Mesh 能力，相当于业务可以不用独立的 Sidecar Proxy，直接通过类似无侵入的方式在应用进程内把微服务的治理、监控、管理、配置等能力增强。同时因为本身是无侵入的，所以可在业务无感知的情况下在应用进程内生效；另外一条路线是基于 eBPF 以及 Istio 最近研发的 Ambient 技术路线。

总结来说是实现微服务四层流量和七层流量分拆的问题。具体来说，在内核态处理四层流量，使用共享数据面处理七层流量，这样就可以逐步实现无 Proxy 的服务网格。因为四层流量是在内核态，不依赖 Proxy。七层流量目前完全做到不需要 Proxy 是非常难的，但是从每一个 Pod 使用一个 Proxy 降级为共享数据面方式，也是向无 Proxy 迈进了很大一步。

二是异构架构的问题。我们团队服务网易内部以及外部的一些合作企业，遇到过非常多异构架构的问题。为了解决这些问题，我们内部提出了“双引擎多模式”的架构。具体来说，我们构建的平台不希望限制业务使用微服务引擎。当然这也是业务提给我们的诉求，不希望一定使用某一种微服务引擎去实现微服务。同时，我们可以支持多种引擎的完整能力，包括 SDK、Agent、服务网格的 Sidecar 以及后续可能的演进，包括 Proxyless 以及多运行时组件。完成这些能力之后再去拉齐不同引擎之间的核心能力，包括通信协议支持不同引擎之间的互访互通以及统一管理。

三是解决技术冗余的问题。以解决网关重叠为例，我们的路线是建设一个七层的通用网关，统一使用服务网格数据面的标准 Envoy 做数据面的选型，进而构建七层通用网关。目标是实现传统的软件代理 Nginx 和新型流量软件比如 API 网关、K8s、Ingress、Serverless 等的合一，这样我们只需要部署一层 Envoy 这样的七层通用网关就可以处理全部七层流量。好处是降低叠加不同组件造成的延时，并解决资源损耗、运维难度加大等问题。

魏诗白：我上述提到了两个问题：一是业务之间的服务相关治理怎么做；二是中间件团队在微服务架构层面如何帮助业务解决复杂度。

第一个方面，公司内部的业务线之间需要考虑的事情是在整个微服务的研发生命周期，包括开发、测试、部署、上线、运维，都要有一整套产研的研发规范。

首先，公司层面需要有基础规范，比如针对域的开发规范，一些明确会引入系统风险的明确禁止，类似研发与规范手册；其次，团队之间需要考虑包之间的依赖冲突问题，我们在公司统一层面需要有一套统一的包管理机制，至少能够解决业务侧不会因为基建的不完善导致研发效率被 block 掉。

公司业务层面需要思考彼此的依赖如何更好解耦。解决方案分为两种：第一种是 SDK 设计更轻量级、更薄。比如，服务应该如何被上游使用方依赖以及服务的 SDK 面向使用方是否足够合理，都需要一些规范去限制，这是业务之间的限制。当然还会有跨业务线、跨部门，比如电商可能会与中台团队做上下游关系的依赖，就需要有底层业务对上层业务支撑的能力，比如需要做好多租户管理和接入规范等。

第二个方面，我们需要思考如何解耦业务与非业务架构，包括现在行业里面比较火的 Service Mesh 都在做这样一个操作，中间件的 SDK 会把服务治理相关能力收敛再下沉，最后再去 Agent 化或者 Mesh 化，进而实现自身的非业务性诉求迭代与业务侧迭代的解耦。解耦之后会极大提升我们对业务侧需求、功能的支撑，不会让公司大规模升级 SDK 版本。

我们一直在通过技术手段解决上述问题，进而帮助业务提升研发效率并解决微服务架构带来的稳定性问题。这个过程需要有些服务治理的手段，比如流量保护机制、固态保护、熔断、可观测性等来帮助用户主动挖掘系统侧的风险，主动规避掉这些问题，比如当业务侧的服务出现线上抖动之后能够主动发现并且一键解决。

微服务架构设计焦点问题探讨

InfoQ 第四问：如何尽量避免过度设计和过度拆分？

魏诗白：我个人的观点是，首先要克制。工程师、架构师们都需要克制对技术的过度追求，贴合公司的实际发展现状，包括当前业务状态以及业务体量。其次是需要衡量当前团队人员背景及行业基本原则，比如两个披萨原则——一位研发同学最多负责的服务数不要超过一定范围，比如 3 到 5 个。因为负责的服务数过多对运维及功能迭代成本带来了很大压力，因此需要根据组织的当前构成考虑问题。

总体来说，一是有些行业中存在微服务的拆分原则，比如领域驱动设计等成熟的解决方案，其本身的理念是组织、团队跟着整个业务形态走，组织与系统架构结合越紧密，越能实现往前迭代的发展，从而避免过度拆分的问题；二是每个人负责的微服务数不要过多，否则会导致整个团队的运维成本陡增。

总结来看，我个人认为微服务拆分的最优解不一定非得是领域驱动设计。第一，肯定要参考当前所在业务团队的整体架构风格，整个领域建模的风格、业务划分的逻辑，不可能自己造一个与团队架构非常不贴合的模式；第二，从公司实际的业务规模出发，如果是初创公司没有必要一上来就用领域驱动设计，还是应该从简。即便是微服务，没有必要为了抽象而抽象，核心观点还是要贴合业务发展。

裴斐：对于过度设计，我认为是经验和目标的问题。比如我们发现团队里面的部分同学由于欠缺架构设计经验会做一些过度设计。一般来说，我们在做设计时，首先要看需要达成的目标，然后围绕目标做针对性设计，并且评估这个设计能不能达成目标。如果恰好可以达成目标，就是一个比较合适且不错的设计，并不是越复杂、越宏观的设计就越好。

InfoQ 第五问：针对遗留系统改造有哪些建议？

郑吉敏：我先说对遗留系统的理解，比如在日常业务迭代中会发现很多当前比较核心的业务，但是 1 到 2 年甚至更长时间的迭代之后，当时所谓的业务场景已经不再有价值，可能会使处理其的系统也变得没那么有价值，这被我们称为遗留系统。

我们公司内部当前也在做这件事情，我们希望团队里的每个人平均维护的服务数在 3 个左右，我们也投入了很多精力。主要分为如下几步：一是公司提供一些基础能力，比如通过工具发现服务里面不经常被调用的代码，基于此评估不被调用的原因再下结论；二是结合业务线对实际业务的理解，比如前年重点做的业务 A 现在因为疫情开始做业务 B，之前的 A 业务本身没有价值了，我们会重新评估该业务是否需要存在；三是梳理或者重点治理时发现部分业务逻辑不清楚，我们会评估该业务价值来决策是否需要关闭入口或者下线服务。在业务关闭之后，相应的代码同样下线，最后对相关系统做整合，尽可能干掉遗留系统。

裴斐：我从架构或者决策层的视角来回答这个问题。以金融领域的合作企业为例，一是选择业务。企业申请业务时建议选择一个准核心业务，既不是直接选非核心业务，因为非核心业务虽然压力小，但是缺少全面的场景覆盖，同时重视程度也没那么高，真出了问题也没那么多人关心，反而达不到试点业务的目标。也不是直接选择核心业务，因为核心业务肯定会有比较大的风险，而准核心业务的风险不会特别大。

二是建设模式。这个问题困扰了我们很久，比如现在有一个比较好的系统，但是业务不是特别好推，这时如何体现我们平台的价值。企业采用了业务系统加技术绑定的方式直接立项，简单来说就是平台和业务部门直接打通，这样不管是目标还是想达到的价值以及在推动改造落地的过程都是有的放矢的，最终也是为了直接方便技术底座或者技术平台呈现价值。

最后是团队结构和决策链。结合业务系统技术底座绑定立项的方式，企业选择的团队同时会做业务开发和技术开发，这样基本是以团队之力把企业里面的试点做完，最终形成遗留系统改造的正反馈。当其他系统看到比较重要的业务以这种方式落地之后也会效仿，这样就可以在企业内部形成比较良性的循环。

魏诗白：关于遗留系统改造，我简单理解就是做系统重构。我认为遗留系统能不动就不动，不动会更好。当然，如果系统本身又焕发一些新的活力，比如某些业务又活过来了。做重构很重要的点就是保证接口不变性，这里重点解答业务验证部分，我们可以引入偏自动化回归测试，保证接口的所有逻辑输入、输出都是同旧系统对等的，这是必须要实现的。我很少用重构改接口定义，因为这需要对上层做改造，这也是领域之间的耦合，而不是重构应该有的状态。接口不变，首先需要有偏自动化的测试验证手段，至少有类似的自动回归测试系统，比如通过引流机制跑这类 Case，做一些覆盖等。当然，核心系统重构肯定也要从自身的经营测试等层面做好相关验证，至少避免由于重构丢失业务逻辑或业务关键数据，进而引入系统风险。

回到最开始的原则，重构也需要克制。如果系统没有导致企业稳定性出现故障，比如导致整个团队迭代效率降低百分之多少等，我建议不要重构，一定要靠实际的痛点去驱动。 

我们公司今年上半年开启了一个新项目，要把一些无用的应用和无效的代码尽可能下掉，但是过程中我们确实踩了一些坑。我可以把这方面的治理经验简单分享下。

第一，有些时候梳理讨论完之后感觉某服务没用了，但实际线上还是有流量的。因此，我们先基于监控把流量降下来，这个过程需要与调用方沟通，在合适的时间降低接口调用频率，确认没有流量请求之后再去做其他事情。

第二，下线应用域名时，我们需要发邮件告知业务方下线的时间、原因及后续解决方案，给业务方足够的时间调整，以防止个别虽然当下没有流量但可能定时在某个时间会被业务方大量调用。

另外，当确定好具体下线的应用时，我们可以先停机一周观察是否出现意料之外的问题，尽量降低潜在影响，动手之前将准备工作做足很重要。

经过一段时间的努力，我们安全地将无效的系统下线，人均运维系统会变少也提升了整体技术团队的幸福感。 

InfoQ 第六问：超大公司的大规模落地实践对于中小企业而言参考价值有多少？

魏诗白：我认为需要看一家大公司是如何从小公司做起来的，以及整个架构演进历程是什么样的，可以与该公司里的资深架构师、资深研发工程师等做一些深度交流。比如我们与字节跳动的技术团队交流时发现他们在 Service Mesh 刚兴起之时就开始做了，所以字节跳动在服务网格层面的进展目前是国内最好的公司之一，当然这与其内部当时出现的一些契机也有关系。

我的核心观点是小公司在看整个大公司的技术演进历程时需要思考不同体量的业务应该具备哪些技术能力，如何向一个正确的方向演进，是否在不同的阶段有不同的侧重点，比如一开始侧重迭代效率，随着业务体量不断增加，侧重点倾斜到稳定性上等，这是大厂实践能够给小厂包括新兴创业公司带来的参考价值。

未来趋势

InfoQ 第七问：如何看待 Dapr 和 Mosn 等运行时的发展？

魏诗白：微软的 Dapr、蚂蚁的 Mosn 以及字节的 Better Runtime......我个人对此持开放态度。从我与大厂的交流经验来看，目前除了字节跳动和蚂蚁金服部分业务落地相对还可以之外，其他大厂还缺少落地实践或者说大规模落地实践。

整个愿景是好的，其核心是如何做好业务与非业务的解耦，并且能够尽量让业务更简洁、更高效地关注应该关注的业务逻辑，而忽视或者尽量做到无感的底层架构、底层中间件相关的特性信息。所以会做类似于把不同的协议，包括不同的中间件，做一个通用接口层的抽象，所有底层类似于往 Bes 化的方向发展。我觉得未来可能是一个趋势，但是目前来说还是缺少比较好的大规模实践经验。

对于小公司，我个人观点是不建议一上来就追随新技术，还是要从实际出发，可能用一个 Spring Cloud 或者 Dubbo 这样的框架就够用了。

裴斐：关于 Dapr，我认为多运行时的架构或者标准非常值得关注，但同时也是一个非常远期的概念。我们关注到非常多的大厂已经在做服务网格，但是实际上对大部分企业来说，尤其是中小型企业，基本上可能需要未来 3 到 5 年这样的周期才能将服务网格普及和大规模落地。

相较于服务网格，Dapr 会更加超前。整体周期上大规模落地可能要 5 年甚至更多的时间去发展以达到真正的成熟，但是我认为这个标准还是非常值得关注的。如果有业务或者技术架构团队想做这种偏底层的新平台时，我认为多运行时这样一个概念的设计不管是模块化还是接口化的能力都值得借鉴。

InfoQ 第八问：Sidecar 是否会被 eBPF 逐渐取代？

裴斐：我们关注 eBPF 较早。我们在做网格优化时已经在用该技术，只不过很多 Cillium 也是想在 Service Mesh 领域更进一步，进而提出了这样一个方案——实现内核态的 Proxyless 。

我认为 Cilium eBPF 跟之前做的容器网络加速非常相关的一点就是 Cilium 更擅长处理四层流量。简单来说，Cilium 可以带来四层流量的安全性、四层监控等能力，四层的流量并不需要一个独立的 Proxy 去处理，而是在内核态用 eBPF 技术就足够了。

反过来再看七层，因为非常多的能力需要在七层处理，这方面并不是 Cilium 的特长，所以在七层选择的时候，还是要选择 Envoy 这样一个服务网格的数据面标准组件去做。这样就形成了四七分离的架构，四层用 Cilium 这种比较成熟的技术，七层用 Envoy 组合，至少要比完全 Proxy 化的方案有进步。

但是具体来说，生产是不是可用，我觉得目前也是一个探索的状态，毕竟这套东西距离真正的完全无 Proxy，或者达到目标态的收益，还有一定的距离。

总的来说，我认为四层上面 Cilium eBPF 做内核态的 Mesh 更合适。对于七层，我认为可以尽量往 Istio、Envoy 方向靠拢。Istio 的方案逐步可以形成 Cilium BPF 跟 Istio Envoy 这两种方案分别在四层和七层形成优势，共同实现无 Proxy 的服务网格。

魏诗白：我结合目前互联网环境的现状做补充，各大公司现在都想降本增效，目前有一个趋势叫逆微服务，譬如随着团队人员规模的缩减，之前的微服务数量肯定也要缩减。具体的操作是把一些服务做组合聚类和重构，组合成更大的微服务来去应对这样的现状。核心理论是适应公司当前的发展现状，我认为一个好的架构是能够适应公司当前的发展现状，并且能够为公司的发展保驾护航，不一定非得是微服务架构。

此外，eBPF 确实可以解决 Sidecar 面临的一些问题，比较直观的是多了两跳这样一个性能问题。以我们公司的实际经验来说，可以对 Sidecar 做一些相关的优化，比如业务进程与 Sidecar 之间可以用 domain socket 做交互，在一些语言比如 Go、Python、Java 上还是有机会在性能层面打平的，未必一定要用 eBPF 的方式去取代 Sidecar。

但是，eBPF 有很多优势，我们公司也在探索阶段，我们更多地是用新兴技术做内核层面的监控和性能分析。但其本身会有内核版本的要求，可能在大型公司应用需要过渡过程，因为内核版本升级是一个高危操作。 

InfoQ 第九问：逆微服务会成为接下来一段时间大家调整的方向吗？

裴斐：我认为微服务不是唯一的正确答案，我认为最主要的是看要解决什么问题，到底能不能达到你的预期，而不是为了做微服务而去做，这会带来更多成本损耗。

郑吉敏：我比较同意裴斐老师的回答，我们一定要看清单体服务或者微服务本身的优势。如果不存在相应痛点，企业不需要特意引入微服务，毕竟引入的同时也带来了其他的复杂性问题。

InfoQ 第十问：对于当前并不确定是否要搭建微服务架构的企业，有哪些建议？

郑吉敏：小公司是否适合搭建微服务架构不是根本性的问题。根本性问题在于当前的微服务化能承载多少人，假设一个单体应用需要太多人维护一定会影响效率。如果要拆分微服务，需要评估技术团队是否能满足，这里面涉及到业务侧和中间件侧，如果团队能力没问题，再评估怎么拆，这又涉及很多拆分原则，需要从架构师到整个团队成员都达成共识。这里面需要经过磨合，让大家都认可一个方向，按照一个目标去努力，否则很容易走偏。

裴斐：首先要看业务场景。如果业务场景确实属于比较小型的业务系统，或者比较底层的技术平台，我认为不太必要搭建微服务架构。但是当业务系统达到一定规模，比如有几十个以上相对独立的业务时，就可以去拆分形成微服架构，此时团队应该考虑怎样搭建这个架构。

另外，需要结合团队的实际情况，基于开源做一些扩展自建或者与相应的服务提供商、公有云平台达成共建。基于开源，建议尽量选择一些细分领域，可以代表技术趋势的一些事实标准的框架去构建。避免因为技术标准小众，或者很容易过时导致无法持续运行。

也可以与服务提供商多交流。假设认为自己团队有实力完成整个架构，可以听一些公开分享或者了解比较成熟的知名服务商是怎样解决通用问题的，以这种方式做一些尽量长远的选择。

但是，如果还是希望与服务提供商达成协作，就需要判断厂商解决异构架构、技术冗余问题的能力等。