构建大规模分布式服务--高并发、高可用架构系列，高质量原创好文

当我们在谈论“服务治理”的时候，都在谈论些什么？

我从业之初接触到的便是一堆基于Webservice、Hessain等实现的跨语言的分布式系统，那是SOA架构和理念十分盛行的时代，我常常听到前辈们在谈论“SOA治理”等高大上的词，但我当时并没有理解何为“治理”，甚至在想：为什么不叫 “管理”呢？在此之前，我仅在小学课本上接触过 “污水治理”这个词。直到近些年互联网企业大规模服务化进程的推进，以Dubbo、Spring Cloud为代表的开源服务框架流行起来，“服务治理”又热门了起来。

那到底何为“治理”呢？大型互联网公司动辄几千上万个应用，而中型公司也至少几百上千个应用。微服务流行后，服务数量更是与日俱增，亟需治理。根本原因还是复杂度过高，需要梳理起来、规范并优化。架构的本质就是管理复杂度，满足不同利益相关者的诉求。下面我将简单的总结下 “服务治理” 领域的各个方面（包括但不限于），便于你建立全面、体系化的理解和认识，以便进一步深入研究和实践

服务定义及管理

服务该如何定义，又该以何种形式暴露出来，上游需要怎么调用，拆分粒度怎么把握…这些都需要统一的规范和约束，否则组织协作很容易乱套。我曾经听到某位架构师讲“微服务就是一个接口一个服务…”，也曾接手过类似的系统，这是典型的 “技术理论派”，永远掌握不了技术或方法论的本质。

再比如我们在开发某项业务功能时发现需要依赖其他域的支持，这就需要了解公司某个子域、某个应用中包含了哪些服务，有没有提供我们想要的业务能力，以及进一步了解服务契约描述长什么样的，这样我们可以快速接入，这就需要好的管理机制和平台支撑。如果是一家创业公司，只有数十个应用系统或者服务，只有20个技术人员，则不会面临类似复杂度，面对面的喊一嗓子就可以了。

但是，最基本的规范和约束在任何规模的团队都是必须的，这里分享些常识经验，例如：接口定义中参数不要使用Map类型，过于灵活的结构往往会导致接口契约定义不清晰，消费方难以理解，而提供方的代码逻辑也将充斥各种判断和特殊处理；

响应结果DTO定义中不要使用枚举，因为如果服务提供者新增了枚举值而服务消费方未升级二方包，是很容易导致反序列化失败，这个在阿里时期曾目睹过类似线上事故；只允许新增接口，不允许修改现有接口的定义，除非你能够确保上游消费者全部统一升级，这个在稍微正常点的公司显然都是不可能实现的；

别看我列举的这些问题好像都很初级，但是很多公司这方面做的确实都很烂，否则技术圈就不会有那么多“前人挖坑，后人填坑”的故事了

服务的注册与发现

服务提供者如何将服务注册上去，消费者端如何快速发现服务、挑选服务，是这个领域要解决的核心问题。开源的注册中心如何选择？注册中心的容量够不够？服务提供者线下后，注册中心能否及时感知并通知消费者？选开源还是自研？这些都是架构师需要考虑的问题。

关于服务注册和发现这里面又会涉及到网络通信，负载均衡，健康检查，数据存储，分布式选举算法和协议等，后面我会有单独的章节仔细展开讲解

服务的调用、路由、容错

服务调用，从通信协议上可以选择TCP/UDP，或者应用层的HTTP协议。从风格上主要有二进制RPC的，或者HTTP+JSON的（这里我纠正一下很多技术人员的认知误区，很多公司所谓的 “Restful”服务其实就是提供的HTTP接口而已。就像很多人口子的 “H5”其实就是一个适配手机屏幕尺寸的小页面，根本没有任何HTML5的新特性）。以RPC框架为例，从编解码层面又会有自定义的私有协议。再往上到应用层又会有序列化和反序列化，采用protobuf序列化还是才是Hessaion2，需要从性能、兼容性、稳定性、跨语言、可读性、可测试性等方面综合考虑

服务路由，这个也很容易理解，比如开源的Dubbo框架中提供的分组管理，这可以理解为是一种路由。HSF中提供的 “同机房优先”能力，这也是一种路由策略。我们有时候需要对服务实现“黑名单、白名单”的过滤保护机制，这就是一种按条件路由。我们在做一些类似“灰度发布、流量染色、环境隔离”等的时候都需要使用到特殊标记然后透传，在服务调用时按规则做路由。当然，更重要的是注册中心的模型设计足够灵活，可以支持类似打tag区分的能力。对于外部的服务而言，我们通过借助网关、Nginx等来实现路由（这种本质上就是请求转发）

服务安全，几乎所有的系统而言通常都需要做身份验证，权限校验等。在分布式微服务架构中，通常我们会将鉴权等横切操作放到网关中，外部应用想要访问服务需要先经过网关，比较通用的就是借助Oath2协议、JWT组件等来实现。而对于内部服务间的调用，因为都是在内网中，会有防火墙等安全手段，基于性能、工作量的考虑ÿ