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

我从业之初接触到的便是一堆基于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组件等来实现。而对于内部服务间的调用，因为都是在内网中，会有防火墙等安全手段，基于性能、工作量的考虑，很多公司不会再单独做鉴权。当然，必要的水平权限校验这些还是很有必要的。另外，在流量接入前通常会设有WAF（web应用防火墙）过滤恶意请求。比较常见的安全问题包括：XSS、SQL注入、DDOS、水平权限等，这里不再继续展开

服务容错模式很多，常见的大概有如下几种：

failfast，快速失败，比如在Java集合框架中当并发对ArrayList等容器做修改、移除等操作时系统就会抛出
ConcurrentModificationException异常，这就是典型的failfast机制。在分布式服务调用中，最常用的failfast机制就是超时，无论是服务提供者还是服务调用者，都需要设置超时;

failover，失效转移，在分布式服务调用中会偶发网络抖动等问题，通常我们会选择另外一台机器进行重试，这就是典型的failover。另外，在数据库、消息中间件领域中，经常会使用类似Master、Slave的架构模型，当发生故障会自动执行主从切换来保障集群的高可用;

failback，失效自动恢复，当请求发生异常或失败时，应该能够保留上下文信息，通过某种机制让其自动重试。比较典型的实现方式就是捕获异常状态，记录日志或者落到 “异常恢复表”中，再通过后台定时任务扫描执行补偿。通常适合对数据时效性、一致性不太敏感的场景;

failsafe，失败安全，当请求发生异常或失败时，简单记录日志后直接忽略，继续推进主流程。比较适合一些非主链路、弱依赖的请求，例如：上报操作日志给大数据平台;

依赖治理

先灵魂拷问下，我的服务被哪些应用依赖了？上游调用量太大会不会把我拖垮？我挂掉了会不会导致上游发生故障？我自己又依赖了哪些服务？他们挂了会不会影响我？哪些是强依赖哪些是弱依赖？这些问题都是需要了然于心的，依赖治理的本质就是管理复杂度，规避或降低风险

服务监控和应急手段

服务监控，主要包括：日志监控、调用链跟踪、度量指标这几块构成，其中的每一块都是一个非常值得深入研究的领域。在云原生时代，我们将其统称为“可观察性”。

大型分布式系统通常由成百上千的应用组成，机器数量也是动辄上千台，是不可能像很早以前一样ssh登录到服务器去执行tail、less的。我们首先需要日志格式统一，日志路径统一，然后对日志进行采集、上报、快速分析、展示和预警。在这个领域，开源社区最流行的代表作是ELK;

前面讲 “依赖治理”的时候已经了解到分布式系统间依赖的复杂性，调用链错综复杂，已经不可能依赖个人经验了。当发生故障或者性能问题的时候，我们需要能够“一目了然”、“顺藤摸瓜”，从而达到快速定位故障或者性能瓶颈的目的。在这个领域的代表作有：pinpoint、cat、skywalking、淘宝鹰眼等以及一些商业化APM;

从应用视角，我们需要了解服务的调用量、成功率/错误率、响应时间等指标。同时，我们也关注线程池、慢查询、连接数等等。从业务方视角，我们需要关注**“当前订单数” 、 “下单总金额” **等类似的业务指标数据。这些指标数据都是跟时间维度相关的，我们需要将这些指标数据保存到时序数据库中，做聚合统计、排名然后展示或者预警；

限流，主要包括：页面限流、接口限流，访问来源或IP限流、单机限流、集群限流、网关限流、热点参数限流，自定义限流等；北京地铁口早晚高峰期的控制，就是典型的 “限流”(通常分 “匀速排队” 和“快速失败”);

降级，从触发条件上可分为：手动降级和自动降级。从场景上又可以分为：一致性降级、完整性降级、用户体验降级、读写降级等;电商在高峰期资源紧张时关闭商品评论服务和推荐服务，这就是一种典型的 “弃车保帅”的降级手段。此外，接口的自动熔断也是一种典型的降级手段;

关于依赖治理、容量规划、限流，降级等后面我会在后续稳定性保障体系的章节中展开仔细讲解

服务测试

服务发布上去之后怎么知道是不是OK的？如果有一个ops控制台，我可以选择服务后直接输入参数、轻松点击就能验证服务通畅是不是很爽？如果在开发联调，或者进行单元测试时，对方没有实现，双方只是确定了服务契约，那我们就需要可以轻松mock数据。在传统的测试体系中，我们通常分为：单元测试、集成测试、组件测试、端到端测试等，形成了经典的 “测试金字塔模型”。

到了微服务时代，我们在 “集成测试”时不同服务间的调用便成为了重点，于是引入了 “契约测试”来保证服务提供者和消费者双方符合规范

小结

从架构师的视角看服务治理，需要关注开发、测试、运维、业务方等（利益相关者）各方的诉求，在技术选型和架构设计时需要权衡取舍，尽可能满足他们的诉求，如图：

究竟什么样的系统算是高并发系统？秒杀就是典型的高并发业务，何谓秒杀场景呢，简单的来说就是一件商品的购买人数远远大于这件商品的库存，而且这件商品在很短的时间内就会被抢购一空。比如每年的618、双11大促，小米新品促销等业务场景，就是典型的秒杀业务场景。

Linux系统在默认的参数下对高并发支持不好，主要瓶颈在于单进程最大打开文件数限制、内核TCP参数方面和IO事件分配机制等。所以下面我们从这几方面进行调优，使Linux系统能够更好的支持高并发环境。

iptables相关

如果不是必须使用，建议关掉或卸载iptables防火墙，并阻止kernel加载iptables模块。这些模块会影响并发性能。

单进程最大打开文件数限制

一般的发行版，限制单进程最大可以打开1024个文件，这是远远不能满足高并发需求的，调整过程如下：在#号提示符下敲入：

# ulimit –n 65535

将root启动的单一进程的最大可以打开的文件数设置为65535个。如果系统回显类似于“Operationnotpermitted”之类的话，说明上述限制修改失败，实际上是因为在中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此，就需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。

第一步，修改limits.conf文件，并添加：

# vim /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

其中’*’号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；65536则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。

第二步，修改/etc/pam.d/login文件，在文件中添加如下行：

# vim /etc/pam.d/login
sessionrequired /lib/security/pam_limits.so

这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。

第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：

# cat/proc/sys/fs/file-max
32568

这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)32568个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。

通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/sysctl.conf文件内fs.file-max= 131072

这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为131072。修改完后保存此文件。

完成上述步骤后重启系统，一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。

如果重启后用ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本/etc/profile中使用ulimit-n命令已经将用户可同时打开的文件数做了限制。

由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次ulimit-n设置的值，因此想用此命令增大这个限制值是不可能的。

所以，如果有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。

通过上述步骤，就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。

内核TCP参数方面

Linux系统下，TCP连接断开后，会以TIME_WAIT状态保留一定的时间，然后才会释放端口。当并发请求过多的时候，就会产生大量的TIME_WAIT状态的连接，无法及时断开的话，会占用大量的端口资源和服务器资源。这个时候我们可以优化TCP的内核参数，来及时将TIME_WAIT状态的端口清理掉。

下面介绍的方法只对拥有大量TIME_WAIT状态的连接导致系统资源消耗有效，如果不是这种情况下，效果可能不明显。可以使用netstat命令去查TIME_WAIT状态的连接状态，输入下面的组合命令，查看当前TCP连接的状态和对应的连接数量：

# netstat-n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
#这个命令会输出类似下面的结果：
LAST_ACK16
SYN_RECV348
ESTABLISHED70
FIN_WAIT1229
FIN_WAIT230
CLOSING33
TIME_WAIT18098

我们只用关心TIME_WAIT的个数，在这里可以看到，有18000多个TIME_WAIT，这样就占用了18000多个端口。要知道端口的数量只有65535个，占用一个少一个，会严重的影响到后继的新连接。这种情况下，我们就有必要调整下Linux的TCP内核参数，让系统更快的释放TIME_WAIT连接。

编辑配置文件:/etc/sysctl.conf，在这个文件中，加入下面的几行内容：

# vim /etc/sysctl.conf
net.ipv4.tcp_syncookies= 1
net.ipv4.tcp_tw_reuse= 1
net.ipv4.tcp_tw_recycle= 1
net.ipv4.tcp_fin_timeout= 30

输入下面的命令，让内核参数生效：

# sysctl-p

简单的说明上面的参数的含义：

net.ipv4.tcp_syncookies= 1
#表示开启SYNCookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse= 1
#表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle= 1
#表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0，表示关闭；
net.ipv4.tcp_fin_timeout
#修改系統默认的TIMEOUT 时间。

在经过这样的调整之后，除了会进一步提升服务器的负载能力之外，还能够防御小流量程度的DoS、CC和SYN攻击。

此外，如果你的连接数本身就很多，我们可以再优化一下TCP的可使用端口范围，进一步提升服务器的并发能力。依然是往上面的参数文件中，加入下面这些配置：

net.ipv4.tcp_keepalive_time= 1200
net.ipv4.ip_local_port_range= 1024 65535
net.ipv4.tcp_max_syn_backlog= 8192
net.ipv4.tcp_max_tw_buckets= 5000

这几个参数，建议只在流量非常大的服务器上开启，会有显著的效果。一般的流量小的服务器上，没有必要去设置这几个参数。

net.ipv4.tcp_keepalive_time= 1200

表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。

ip_local_port_range= 1024 65535

表示用于向外连接的端口范围。缺省情况下很小，改为1024到65535。

net.ipv4.tcp_max_syn_backlog= 8192

表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_max_tw_buckets= 5000

表示系统同时保持TIME_WAIT的最大数量，如果超过这个数字，TIME_WAIT将立刻被清除并打印警告信息。默认为180000，改为5000。此项参数可以控制TIME_WAIT的最大数量，只要超出了。

内核其他TCP参数说明

net.ipv4.tcp_max_syn_backlog= 65535
#记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。

net.core.netdev_max_backlog= 32768
#每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
net.core.somaxconn= 32768

例如web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，所以有必要调整这个值。

net.core.wmem_default= 8388608

net.core.rmem_default= 8388608

net.core.rmem_max= 16777216 #最大socket读buffer,可参考的优化值:873200

net.core.wmem_max= 16777216 #最大socket写buffer,可参考的优化值:873200

net.ipv4.tcp_timestsmps= 0

时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。

net.ipv4.tcp_synack_retries= 2

为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量。

net.ipv4.tcp_syn_retries= 2

在内核放弃建立连接之前发送SYN包的数量。

#net.ipv4.tcp_tw_len= 1
net.ipv4.tcp_tw_reuse= 1

开启重用。允许将TIME-WAITsockets重新用于新的TCP连接。

net.ipv4.tcp_wmem= 8192 436600 873200

TCP写buffer,可参考的优化值:8192 436600 873200

net.ipv4.tcp_rmem = 32768 436600 873200

TCP读buffer,可参考的优化值:32768 436600 873200

net.ipv4.tcp_mem= 94500000 91500000 92700000

同样有3个值,意思是:

net.ipv4.tcp_mem[0]:低于此值，TCP没有内存压力。

net.ipv4.tcp_mem[1]:在此值下，进入内存压力阶段。

net.ipv4.tcp_mem[2]:高于此值，TCP拒绝分配socket。上述内存单位是页，而不是字节。可参考的优化值是:7864321048576 1572864

net.ipv4.tcp_max_orphans= 3276800

系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。

如果超过这个数字，连接将即刻被复位并打印出警告信息。

这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，

更应该增加这个值(如果增加了内存之后)。

net.ipv4.tcp_fin_timeout= 30

如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN-WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些。

同时还涉及到一个TCP 拥塞算法的问题，你可以用下面的命令查看本机提供的拥塞算法控制模块：

sysctlnet.ipv4.tcp_available_congestion_control

对于几种算法的分析，详情可以参考下：TCP拥塞控制算法的优缺点、适用环境、性能分析，比如高延时可以试用hybla，中等延时可以试用htcp算法等。

如果想设置TCP 拥塞算法为hybla

net.ipv4.tcp_congestion_control=hybla

额外的，对于内核版高于于3.7.1的，我们可以开启tcp_fastopen：

net.ipv4.tcp_fastopen= 3

IO事件分配机制

在Linux启用高并发TCP连接，必须确认应用程序是否使用了合适的网络I/O技术和I/O事件分派机制。可用的I/O技术有同步I/O，非阻塞式同步I/O，以及异步I/O。在高TCP并发的情形下，如果使用同步I/O，这会严重阻塞程序的运转，除非为每个TCP连接的I/O创建一个线程。但是，过多的线程又会因系统对线程的调度造成巨大开销。因此，在高TCP并发的情形下使用同步I/O是不可取的，这时可以考虑使用非阻塞式同步I/O或异步I/O。非阻塞式同步I/O的技术包括使用select()，poll()，epoll等机制。异步I/O的技术就是使用AIO。

从I/O事件分派机制来看，使用select()是不合适的，因为它所支持的并发连接数有限(通常在1024个以内)。如果考虑性能，poll()也是不合适的，尽管它可以支持的较高的TCP并发数，但是由于其采用“轮询”机制，当并发数较高时，其运行效率相当低，并可能存在I/O事件分派不均，导致部分TCP连接上的I/O出现“饥饿”现象。而如果使用epoll或AIO，则没有上述问题(早期Linux内核的AIO技术实现是通过在内核中为每个I/O请求创建一个线程来实现的，这种实现机制在高并发TCP连接的情形下使用其实也有严重的性能问题。但在最新的Linux内核中，AIO的实现已经得到改进)。

综上所述，在开发支持高并发TCP连接的Linux应用程序时，应尽量使用epoll或AIO技术来实现并发的TCP连接上的I/O控制，这将为提升程序对高并发TCP连接的支持提供有效的I/O保证。

经过这样的优化配置之后，服务器的TCP并发处理能力会显著提高。以上配置仅供参考，系统调优需根据实际环境调整观察再调整，并不是一蹴而就的。

云技术在线提供Linux系统调优、系统运维服务。