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

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

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

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

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

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

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

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

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