18 如何设计微服务才能防止宕机？

在上一讲里，介绍了构建一个稳健的微服务的具体法则：防备上游、做好自己、怀疑下游，并介绍了为什么要防备上游，以及一些防备上游的具体手段。

在本讲里，咱们一起来学习，做好微服务自身的设计和代码编写的常见手段。

微服务 CPU 被打满如何排查

在讲解具体有哪些手段可以用来构建一个更加稳固的微服务前，咱们先来看看如何高效、精准地定位问题。下面我将以设计不精良的微服务在线上最容易产生的问题：“机器 CPU 被打满”为例进行讲解。

这个问题也是面试中的高频话题，很多面试者能够回答出其中一二，但距离让面试官满意的答案还有一定距离，下面咱们就一起来看看详细的排查步骤。

一台机器上会部署一至多个进程，它们可能是一个或多个业务应用进程和多个其他工具类进程（比如日志收集进程、监控数据收集进程等）。大概率导致机器 CPU 飙升的是业务应用进程，但仍需准确定位才可得出结论。

在 Linux 系统里，可以使用top 命令进行定位， top 命令可以按进程维度输出各个进程占用的 CPU 的资源并支持排序，同时还会显示对应的进程名称、进程 ID 等信息。

根据排序，便可以确定占用 CPU 资源最高的进程，但此时仍然不知道是哪段代码导致的 CPU 飙升。所以可以在此进程基础之上，做进一步的定位。top 命令支持查看指定进程里的各线程的 CPU 占用量，命令格式为：top -Hp 进程号。通过此方式便可以获得指定进程中最消耗 CPU 资源的线程编号、线程名称等信息。

假设导致 CPU 飙升的应用是基于 Java 开发的，此时，便可以通过 Java 里自带的 jstack 导出该进程的详细线程栈（包含每一个线程名、编号、当前代码运行位置等）信息，具体见下方示例代码：

"thread name" prio=0 tid=0x0 nid=0x0 runnable at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171)

通过第三步定位的线程号和此步骤生成的线程栈，便可以精准确定是哪行代码写的有 Bug，进而导致进程的 CPU 飙升。上述分析是以 Java 应用进行举例，关于其他语言的应用如何导出进程堆栈信息，你可以到对应官网查看。如果有疑问也可以写在留言区，我们一起交流。

如何预防故障

上述介绍了，当微服务的代码编写不优雅，导致 CPU 飙升时，如何快速、准确应对的方法。下面将从微服务的部署和代码编写两个层面介绍一些准则，以便构建一个更加稳固的微服务，前置减少出现故障的概率。

部署层面

首先，微服务及存储需要双机房部署。双机房部署能够进一步提升服务的容灾能力。双机房部署的架构如下图 1 所示：

图 1：双机房部署架构图

上述部署里，同一个微服务分别在两个机房各部署了两台机器。在存储上，数据库的主从分别部署在两个机房里。当出现机房级别的故障，如网络不通时，可以直接将故障机房的机器从微服务的注册中心摘除。其次，如果故障发生在主库所在机房，就需要 DBA 进行协助，对主从数据库的数据对比、订正并进行数据库的主从切换。

双机房部署使得微服务具备了机房级别的容灾能力，当机房出现故障时，可以快速地进行切换，而不用耗费几个小时甚至更久的时间，在一个新的机房进行微服务和数据库的重新部署。但上述的部署里，数据库其实是单机房部署的。因为在实际运行时，只有主库承载读写流量，从库只是跨机房进行数据复制，作为灾备使用。

当真正出现机房故障时，整个微服务仍需停服一定时间，用来等待 DBA 进行主从切换，原则上只在秒级或者分钟级别。这在绝大部分场景里均可满足业务的需要，但有些用户使用高频的场景，如打车、即时通信等软件，需要业务尽可能 7*24 运行，减少或保障不出现业务停服的场景。对于此类需求，可以采用存储按机房多地部署、且每个机房的存储均支持部分用户的数据读写的方案进行升级，此方式在业界有个特有名词，叫作单元化部署的架构，具体架构如下图 2 所示：

图 2：单元化架构图

在单元化架构里，两个机房里的数据库均为主库，它们都承载读写流量。此外，对于用户的请求流量，在网关层进行了转发，一部分转发至机房 A，另外一部分转发至机房 B。假设当机房 A 出现故障时，机房 B 所承载的流量是完全不受影响的，即路由至机房 B 的用户对于故障无感知。

而对于机房 A 里的用户，则可以在网关层进行前置再路由，将所有的请求全部转发至未故障的机房 B。在上图 2 中，有一条两个机房里的数据库主库互相同步的标识线，它是单元化里需要构建的数据同步模块。作用是发生故障时，减少机房 A 里的用户切换到机房 B 的时间。因为机房 A 里的用户可以切换到机房 B 的前置条件是，机房 A 里的数据已经全部同步至机房 B 里，实时的数据同步可以减少故障后 DBA 进行数据同步、对比和校准的时间。

可以看到，单元化架构并不是机房故障后，对于业务完全无损，而是保障一部分用户完全无损来提高高可用能力。

其次，机房内至少部署两台及以上机器。这里再多啰唆一句，上述第一条要求至少双机房部署，并不是两个机房各部署一台机器即可，而是要在同一个机房里至少部署两台机器，保障机房内机器互相灾备。此方式可以防止当某一台机器故障后，出现整个机房全部失联，进而将调用方的所有的流量都打至另外一个机房，引起请求的性能和稳定性下降，因为跨机房的请求的网络传输时间更长。单机房部署单容器故障时导致的跨机房调用的架构如下图 3 所示，可以看到故障后，调用方的所有流量全部都路由至被调用方的单个机房里。

图 3：机器故障导致的跨机房架构图

再者，不同类型的接口需要单独部署。在模块二和模块三里介绍过读服务和写服务的特点，这里再复习一下。读服务的特点是调用次数特别大，对于性能要求高。而写服务则是对于稳定性要求特别高，调用次数相比读服务会低很多。假设你在微服务拆分时，没有在垂直拆分时按读写分离的方式将读和写服务拆分开，而是将代码编写在同一个工程里。那么部署的时候，建议将二者的接口拆开部署，拆开后的结构如下图 4 所示：

图 4：读写分离的部署架构

隔离开单独部署主要有以下几点考虑。

写服务对于稳定性要求较高。隔离后，读服务里因为代码 Bug 等因素导致的机器 CPU 飙升、内存占满等问题不会影响到写服务的性能和稳定性。

其次，读服务调用量较高，对于机器 CPU、内存、网络等占用也较高。隔离后，写服务将独享机器资源，性能和稳定性也较好。

最后，微服务的执行线程是根据机器的 CPU 提前设置好的，大小是固定的。读写混合部署时，读请求很容易将微服务框架的执行线程沾满，导致线程枯竭，进而导致写请求得不到执行。此时，通过隔离部署也可以解决此问题。

最后，至少要线程池隔离。在某些时候，可能读服务的调用次数并不是特别大或机器资源有限，实现不了上述的纯机器隔离。此时，可以实现一个简版的隔离，即微服务框架的执行线程池隔离。现在主流的微服务框架都支持对于接口单独配置一个执行线程，这样在执行时，就可以做到线程池资源隔离，互不影响，具体架构见如下图 5 所示。在某些无法完成机器隔离的场景里，可以使用此方式实现一定程度的资源隔离。

图 5：线程池隔离架构图

代码层面

有很多编写优雅、易阅读、易维护代码的技巧，因为篇幅和专栏定位原因，此处并不会一一介绍，此小节主要聚焦如何编写避免系统故障的编码准则。主要包含以下几点。

第一，不要基于 JSON 格式打印太多、太复杂的日志。

假设有一个特别复杂的类，其中包含了几十上百个字段，同时某些字段也是对象类型，该字段又嵌套了很多对象字段。如果在日志输出时，直接将该类通过 JSON 进行序列化，并进行日志输出，伪代码格式如下：

复杂Object obj=new 复杂Object(); logger.info(JSON.toJson(obj));

如果每一次请求，微服务的代码都会按上述格式打印日志，那么当调用量稍微上升时，很容易将微服务的 CPU 占满，进而导致服务宕机。导致上述现象的主要原因是：复杂的对象在序列化时非常消耗 CPU 资源。建议在打印日志时，按需输出。采用 toJson 方式序列化大对象，很多时候因为简单、粗暴，不需要太多开发量，所以就被研发同学大量、广泛地使用，与此同时也带来了系统宕机的风险。两害相较取其轻，建议采用如下按需的方式输出日志，规避宕机风险。

logger.info("内容1:{},内容2:{},内容3:{}",具体内容1,具体内容2,具体内容3);

第二，需要具有日志级别的动态降级功能。

假如上述按需输出日志的方式还没有被大家广泛接受，你还是习惯使用 toJson 的方式输出日志。那么为了防止打印日志导致机器宕机，需要在日志输出前进行级别判断，使得当日志打印导致机器出现问题时，通过此方式可以将日志进行关闭。具体写法如下：

if(logger.isInfoEnabled()){ 复杂Object obj=new 复杂Object(); logger.info(JSON.toJson(obj)); }

当 toJson 的日志打印把 CPU 占满之后，可以将日志级别调整为更高等级，比如 error 级别，禁止日志输出即可规避问题。此外，更进一步的是，此日志级别调整可以开发动态功能，结合配置中心，动态的修改日志级别，可以实现不重启应用即可生效日志级别修改的功能。

第三，for 循环不要嵌套太深，原则上不要超过三层嵌套。

实践中，for 循环迭代的数据是从数据库或远程 RPC 获取的，获取到的数据量是动态的，可多可少，极端情况下可能多达上千条。此时，三层嵌套下的时间复杂度则为：O(10003)=10 亿。上亿次的代码执行，分分钟就会把微服务打挂，建议在代码编写时，规避此种写法。

第四，多层嵌套需要有动态跳出的降级手段。

假设业务上无法规避上述的多层嵌套，在实现时，需要在嵌套内部开发主动跳出的降级开关。当上述数据量增多时，此方式可以通过开关主动地跳出嵌套，防止机器宕机。

第五，如果使用应用内的本地缓存，需要配置容量上限。

如果不显式地配置本地缓存的容量上限，有可能因为容量暴涨，导致进程 OOM。因此，需要根据机器的内存大小显式地配置本地缓存的容量上限。