随着业务规模迅速扩大，微服务成为各企业采用的主要架构形式，这给开发团队带来了极大好处：
- 每个服务足够内聚，代码容易理解、开发效率提高;
- 服务之间可独立部署，微服务架构让持续部署成为可能;
- 每个服务可以各自进行负载均衡扩展和数据库扩展，并根据自己的需要部署到合适的硬件服务器上;
- 独立开发使新技术应用更加灵活。
画外音：高内聚、低耦合，是技术团队努力想要达成的六字真言。
微服务想要真正落地有一定的技术门槛：
- 一是进行服务拆分，边界在哪儿?怎么取舍?什么样的粒度才符合“高内聚、低耦合”;
- 二是微服务上了规模之后如何管理?因为只要上了规模，任何小问题都可能会被放大，最后导致雪崩效应。
举个例子，多个相同的微服务可以做负载均衡，提高性能和可靠性，但微服务本身是不会去关心系统负载的，什么时候该启动更多的微服务，多个微服务的流量如何调度和分发，这背后需要有一套复杂的负载监控和均衡的系统发挥作用。
对开发团队来说，如果没有搞清楚如何进行服务治理，盲目进行架构调整无异于一场灾难。画外音：服务治理是通向微服务架构的第一关。
服务治理是一个大话题，包括服务注册发现、请求链路追踪、服务熔断、服务限流、服务管控配置、服务预警等等。
回归实际业务场景：
- 故障定位非常困难，出了问题，各查各的，非常低效，怎么实现高效定位;
- 秒杀的时候，所有的监控系统、链路跟踪系统都要是可以降级的，不能因为这些东西导致整个系统崩溃;
- 超时配多少是合适的?100 ms?300 ms?极端情况有些业务配到 3 秒的，很多程序员并不清楚超时设成多少合适;
- 你无法无限制的接受请求，不可能 100 个并发就接收 100 个，并发到底怎么配，怎么限流?
画外音：关于服务治理，我最重要的经验是做好保护与自我保护。
对开发人员来说，难点往往在于无法将积累的知识串联起来，形成系统知识结构，只停留在机械应用层面，无法根据业务场景与底层逻辑进行匹配，最终无法形成解决问题和举一反三的能力。
思路往往比过程更重要，掌握了底层逻辑，形成思维模型，工作起来就会有豁然开朗的感觉!
【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】
【责任编辑：赵宁宁 TEL：（010）68476606】
