干货！谈谈服务可用性及其优化

良心公众号

关注不迷路

随着互联网行业的逐渐深耕下沉，服务的可用性，尤其是在线服务的可用性，在系统架构的设计方面的重要性与日俱增。可以说，服务的高可用是对在线服务最基本的要求。

因此，对服务可用性有自己的见解，并且具备根据具体业务场景进行服务可用性优化的能力，就显得尤为重要。

菜鸡将在本篇文章中，谈谈对服务可用性的理解，及其优化的思路。

为了避免单纯的理论陈述太过干涩，我们不妨以在线服务技术更迭的历程为主线，从其发展的过程中寻找一些关于服务可用性及其优化的端倪。为什么一直强调是在线服务呢？因为相对于离线服务而言，在线服务的可用性要求显然是更高的。也就是说，在线服务对可用性更加敏感。

现在，假设你是一个创业公司的CTO，公司一个核心项目是一个To C的在线服务。让我们带入这个场景，来模拟一下在线服务技术更迭的主要过程。

首先，在该项目刚刚上线时，由于用户较少，因此，服务的压力比较小，即便是部署在单台机器上，也能对用户的请求作正常的处理和应答（仅仅用作举例，一般在线服务至少要部署在两台机器上，防止单点问题）。此时，我们称该服务为单机服务。这种情况下，一般对数据库的要求也不高，即使单体也能够正常工作。这时候需要考虑的点比较简单，开发的重点是丰富业务功能，完善业务场景，优化使用体验。

然后，随着业务功能的丰富和业务场景的完善，以及用户体验的优化，用户人数逐渐增加，请求的流量也日渐增长。慢慢的，单机的性能就难以承担这个级别的流量了（单机的性能与机器的具体指标有关）。这时，需要对服务进行横向扩容。通俗点说，就是将服务部署在多台机器上，分散请求流量，多台机器并行处理这些流量，降低单台服务器的压力。这时候，就需要引入负载均衡（一般可以用nginx作负载均衡，也可用gateway作负载均衡）的概念，通过实施符合实际情况（需要考虑服务请求情况、机器性能等因素）的负载均衡策略，来将请求的流量相对合理地分配到各个服务器上。在业务进行技术更新迭代的同时，数据库也需要做对应的升级，比如搭建数据库集群，引入redis等非关系型数据库等等。

用户量的增长，对服务所能支持的业务提出了更多要求，业务逻辑越来越复杂，代码的可读性和可维护性难度日益增加，如果运气好的话（手动狗头），一些不合理的设计会导致服务有状态化，变得难以横向扩容。这时候，就需要将服务的业务进行拆分，搭建多个较小的服务模块，这就形成了最近特别热门的微服务架构。

谈及微服务，很多小伙伴马上就想到了Spring Cloud，需要明确的是，这只是一套比较成熟的微服务解决方案，而不是微服务本身。也就是说，通过拆分大的服务得到若干个微小的服务，就是微服务。而微服务的诞生是喜忧参半的，它帮助我们解决了随着业务逻辑复杂性提高随之带来的代码可读性和系统可维护性降低，以及难以横向扩容等问题，但同时又引入了新问题，比如，服务之间的如何相互发现，如何相互调用，以及如何拆分数据源等等一系列棘手的问题。

好在经过前人的不懈努力，针对上面的问题，我们终于拥有了一套生产级的解决方案（不一定就是Spring Cloud），比如，服务间发现，我们可以使用Zookeeper，可以使用Spring Cloud提供的Eureka，还可以使用Spring Cloud Alibaba提供的Nacos等等；再比如，服务间调用，可以通过像Thrift这样的服务间远程过程调用（RPC）框架来实现，也可通过HTTP请求实现。由于在线服务一般对请求时延的要求比较高，因此，我们一般选择效率更高的RPC方式而非适用场景更广的HTTP方式。

到这里，当然还不是服务可用性优化的尽头，事实上，我们还有很多事情可以做，比如，加入配置中心（比如Apollo或者Nacos等）来实现参数动态修改、灰度发布等一系列大型在线服务常用的功能。

再比如，对于多个有关联性的服务做服务隔离，服务熔断，服务降级（可以使用Hystrix或者Sentienl等来实现），另外，针对具体的业务场景，做好限流以及监控等功能，做到某个服务出了问题不影响其他服务，辅助服务出了问题不影响关键服务，超量流量不会打垮服务，以及出了问题能够及时发现并定位等等。

随着不断地优化，就慢慢形成了一套庞大的高可用的在线系统……

服务可用性没有最高只有更高，追求在线服务的高可用意义非凡，需要很多实践探索，以及经验教训的学习与总结，本文只是概述了一些比较通用的服务可用性及其优化的思路，供大家参考。

欢迎大家一起讨论技术，共同成长！

学习 | 工作 | 分享

????长按关注“有理想的菜鸡”

只有你想不到，没有你学不到