随着业务规模迅速扩大，微服务成为各企业采用的主要架构形式，这给开发团队带来了极大好处：

• 每个服务足够内聚，代码容易理解、开发效率提高;
• 服务之间可独立部署，微服务架构让持续部署成为可能;
• 每个服务可以各自进行负载均衡扩展和数据库扩展，并根据自己的需要部署到合适的硬件服务器上;
• 独立开发使新技术应用更加灵活。

画外音：高内聚、低耦合，是技术团队努力想要达成的六字真言。

微服务想要真正落地有一定的技术门槛：

• 一是进行服务拆分，边界在哪儿?怎么取舍?什么样的粒度才符合“高内聚、低耦合”;
• 二是微服务上了规模之后如何管理?因为只要上了规模，任何小问题都可能会被放大，最后导致雪崩效应。

举个例子，多个相同的微服务可以做负载均衡，提高性能和可靠性，但微服务本身是不会去关心系统负载的，什么时候该启动更多的微服务，多个微服务的流量如何调度和分发，这背后需要有一套复杂的负载监控和均衡的系统发挥作用。

对开发团队来说，如果没有搞清楚如何进行服务治理，盲目进行架构调整无异于一场灾难。画外音：服务治理是通向微服务架构的第一关。

服务治理是一个大话题，包括服务注册发现、请求链路追踪、服务熔断、服务限流、服务管控配置、服务预警等等。

回归实际业务场景：

• 故障定位非常困难，出了问题，各查各的，非常低效，怎么实现高效定位;
• 秒杀的时候，所有的监控系统、链路跟踪系统都要是可以降级的，不能因为这些东西导致整个系统崩溃;
• 超时配多少是合适的?100 ms?300 ms?极端情况有些业务配到 3 秒的，很多程序员并不清楚超时设成多少合适;
• 你无法无限制的接受请求，不可能 100 个并发就接收 100 个，并发到底怎么配，怎么限流?

画外音：关于服务治理，我最重要的经验是做好保护与自我保护。

对开发人员来说，难点往往在于无法将积累的知识串联起来，形成系统知识结构，只停留在机械应用层面，无法根据业务场景与底层逻辑进行匹配，最终无法形成解决问题和举一反三的能力。

思路往往比过程更重要，掌握了底层逻辑，形成思维模型，工作起来就会有豁然开朗的感觉!