微服务治理

服务监控治理

微服务治理平台

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

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

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

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

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

一是业务之间的服务相关治理怎么做；二是中间件团队在微服务架构层面如何帮助业务解决复杂度。

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

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

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

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

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

如何尽量避免过度设计和过度拆分？

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

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

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

针对遗留系统改造有哪些建议？

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

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

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

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

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

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

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