笔者自入职我司有一年了，并有幸参与我司后端系统的一些基础服务开发和基础库的编写。这一年多的开发实践，踩了不少坑，也积累了一点实战经验。笔者主要结合实际工作中的积累或者是踩过的坑，谈谈如何构造更高可用、体验更好的web后端系统，希望能抛砖引玉。
先来个具体例子，比如app网关接口通常是聚合型的，为了最大程度提升系统的性能和稳定性，那么需要分析接口的整个链路。有哪些请求依赖，有哪些是可并行的，哪些是必须串行的，哪些是可以降级的，哪些是可以返回空的，哪些是必须返回err的等等。这样，才能最大程度提升系统的稳定性和性能。以下，从几个点来谈谈系统的实战经验。
1.高可用
- 容错和降级。 容错级别上，忽略次要 error < 服务降级 。程序中部分error是可以忽略处理的，或者打个日志标记下，而不用结束整个执行流程。服务降级是指，当依赖的非核心模块出问题时，可以选择不请求或者熔断式请求(过载保护)，数据可以不吐给客户端，这就要求对数据或者服务进行级别划分，优先保证用户的基础体验。如果对实时性要求不是特别高的，可以将上次请求的数据缓存下来做灾备数据，这个做法在聚合类接口提供系统可用性上非常有帮助。
- 容灾 通常就包括机器的容灾和机房的容灾。如果是HTTP SERVER，一般SLB这里会有PING CHECK，如果某台机器挂掉SLB会切掉这台机器。如果是RPC SERVER，节点挂掉也会自动摘掉这个节点。机房容灾也是很有必要的，也许突然某个时候机房的网线电缆被挖断了呢！相比于机器容灾，机房容灾的成本也是比较高的。前期技术成本考虑，倾向于一主一备，毕竟双写的技术要求是比较高的。
- 隔离 隔离包括逻辑隔离和物理隔离，逻辑隔离是指多进程隔离啊、不同mysql实例啊、业务拆分隔离啊、docker化等等，还有包括cache、db、文件存储系统等都需要做隔离。而物理隔离一般指机器隔离部署、多机房方案等，它和逻辑隔离互为补充的。还有一种架构上的隔离，比如几个大的核心业务同时依赖基础核心数据cache，那么这个cache也可以做多份隔离。隔离是避免因为其他业务的突发流量或者异常访问或者无法预期的问题，从而引起影响整个系统甚至影响所有业务。我们的微服务系统采用group化进行隔离和扩容。
- 缓存 通常考虑两种场景。第一种，数据是本身的，比如是业务本身的db数据，所以要给自己加cache，通常能挡90%以上的读流量，这样相对于只访问数据源则多了一种可靠方案。另一种场景，A模块依赖B模块的数据，很多时候A还要作一层甚至两层cache。比如A做一个local cache，配置成unix sock方式(更甚一步是放内存里)，过期时间比较短，以满足业务上的实时性要求（或者配置时间长，通过订阅事件去更新）。另外还会加一个remote cache，过期时间很久。当local cache没有命中时会访问数据源B，而当B挂掉的时候，我们可以读remote cache，相当于降级处理，因此能提高系统的可用性。这里A和B的cache操作是几乎一样的，实现成本很低。
- 限流 任何一个服务端系统总是也承载上限的，与其忽略这个问题，不如给系统做压测设上限，在流量突发时能至少保证系统不挂。触发限流的原因有很多，有时是业务突发上涨，有时是前端BUG，有些是异步任务堆积，甚至有时是受到人为攻击。通常整个网站的入口SLB并非能准确限制某个业务的流量，所以各个业务自身也要考虑限流。从网关到业务模块到数据模块，整个链路全部都要做限流！否则瞬时的流量峰值可能会把系统的某个节点打挂，从而影响整个系统，甚至很可能引发雪崩效应。我司的限流也是在基础框架做的，使用的令牌桶算法，业务代码只要注册下要限流的接口即可。同时作为client，也要做限流保护后端，比如熔断降级、请求合并等。
- 弱化核心依赖 一个系统如果没有核心依赖就无敌了，当然现实中很难避免，通常要做的是弱化或者隔离分散压力。举个工作中的例子。业务很多接口都依赖用户身份校验或者接口签名校验，而检验是走帐号代理的rpc接口做的。帐号代理除了做校验，还是个基础服务，经常要做功能或技术迭代，所以也大大小小出了几次小故障。但是却影响了几乎所有的模块！所以要隔离，不过我们做的更彻底，没有拆成服务，而是以基础库的方式，业务自己直接访问认证cache和校验，同时缓存也做了隔离。这次几乎看不到校验的逻辑了，再也没出过问题。还有个实例，我们业务cache之前都是走tw集群代理，但是因为各种原因tw集群本身出过几次问题，于是我们将tw本地化，做彻底隔离，稳定性好很多，当然配置变更会麻烦一些。
2.高性能
高性能体现在两个方面，一个是低延时，一个是高并发。怎么做到呢？
- 怎么降低延时呢？缓存+异步+并行+超时 缓存就不用说了，内存比IO快是肯定的。能异步的尽量异步，比如更新cache、事件通知；并行对于数据聚合接口也是很有效的，尤其有时候要访问几个甚至更多依赖服务的时候，同步的串行访问耗时是非常大的，golang可以参考下errgroup这个库。超时更是降低延时的一大利器，通常超时的时间是基于依赖模块的统计确定的，而且不能过于妥协。
- 代码质量把关。这个点非常广，简单谈谈。一般有减少大锁（大拆小、用CAS）；尽量使用批量协议（规避小包），比如redis的pipeline，包括业务协议上也需要支持批量；尽量使用指针或者引用传递变量以避免无意义的大内存拷贝；程序的逻辑框架的合理性，比如如何扩展支持并发扩展等；golang这块还要考虑尽量不要滥用goroutine、尽量复用对象来减少gc（比如sync.Pool）、少用defer、少用反射（耗性能）。
- 配置参数。程序依赖的各种资源的配置要适当。通常涉及时间的有dial timeout、read timeout、write timeout、idle timeout，具体依赖实际的服务端场景、物理环境和统计数据，时间太短会很敏感，读写超时时间一般略大于server端处理的最大时间，比如cache超时时间加db超时时间。涉及连接池的有最大活跃、最大空闲，配置太小可能导致高峰期满足不了并发量，配置太大可能导致资源滥用影响服务端甚至影响其他业务。还有就是机器部署上的配置，容量上的配置还有CPU内存资源等都要充足，至少要有50%的冗余。不确定的都检查下吧。
- 压测和线上数据分析。我相信绝大多数的业务场景，无论是吃CPU的、吃IO的、吃内存的、各种业务代码质量、BUG，通常都能通过压测表现出来。我倾向于线上环境压测或者观察高峰期数据，哪里“压爆了”就从哪里找问题优化，或者观察高峰期哪里容易抖动或者哪里吃最大的cpu或者内存都可以作为分析点。
３.易扩展
扩展性，对业务服务器来说，一般来说主要就是尽量做到无状态，如果确实有状态数据，可以放到更高可用的系统里，比如zookeeper、redis等，笔者之前参与开发的小文件系统就是将存储节点的相关元数据放到zookeeper里，这样调度节点就非常轻量级接近无状态。另外就是服务需要支持健康检查、自动注册和发现，比如rpc server可以直接注册到zookeeper实现自动扩容等等。
4.合适的架构
没有最好的，只有最合适的。在技术选型上也是如此。比如落地存储有些写量大的用hbase还是mysql呢？如果没有牛x的hbase维护还是用mysql吧。又比如cache集群用官方的集群还是tweproxy代理呢，还是超级client，得看公司运维的水平或者人力投入。再比如要不要做cache，要看是否有很高的命中率以及对数据的实时性要求，或者缓存更新通道是否稳定等等，当然一般这些是要解决来满足cache的。还有诸如机房容灾要不要做，是做成双主还是一主一从，数据库分表是哈希硬编码还是使用中间件等等，总之，技术选型一定要考虑到业务场景（业务需求）、运维资源和水平、开发投入、稳定性和扩展等各方面，一味的追求牛x的架构不一定合适。
