后台服务架构小结

前言

在互联网团队中，产品关注用户体验和产品价值、算法关注算法准确度、前端UI关注用户交互页面展示，而后台工程师关注点更偏重于服务架构和业务实现。

本文谈谈什么是（后台）服务架构，什么是好的服务架构，服务架构的目的是什么？

什么是服务架构

系统架构是定义系统的结构、行为及其他视图（view）的概念模型。

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。

后台服务架构是软件架构的一种，是针对后台服务的架构。

（后台）服务架构的目的

本文讨论的是针对后台的后台服务架构。后续简称服务架构。

服务架构的目的，是让企业、团队、部门提供的后台服务具备高可用、高扩展、高性能、可观察等4个方面的能力。从而降低运维成本、降低新需求开发成本、保障用户体验、提升用户幸福感。也是一个公司、技术团队管理能力、专业能力、技术实力的体现。打造口碑和影响力。

服务架构的4个目的

高可用

高可用一般是服务架构的底线要求。

我把高可用分为两类，一是服务治理，二是服务容灾。两把刀相辅相成，不是完全独立的。高可用与其他几个目的的保障措施也是相辅相成的。举个例子，服务的服务器发生单机问题，服务应有自动的容错机制，重试机制（服务容灾），并且在负载均衡上及时摘除问题节点（服务治理），同时通过监控指标及告警，及时周知负责人或运维（可观察）。服务的用户对于底层发生的单机问题几乎是无感知的。

有大量的文章，对服务治理、服务容灾有详细的介绍。我在这里不展开这些，单独记录一下对于服务健康检查的认识。服务可用性是指服务保持稳定态占整个时间周期的比率。可靠性指的是服务启动后直到第一次故障的时长，越长越好。服务可用可以等价理解为服务健康。那么服务健康检查，对于服务的可用性保障是十分关键的。

服务健康检查的实现可以是一个返回服务是否健康的接口，可以间隔上报心跳，可以自行实现，也可借助框架（比如spring acutator中的health entry point）。实现了健康检查机制后，在服务注册、负载均衡、坏点发现与摘除上便有了一个精确有效的指标。从而大大提高服务在新部署接流、单机故障时的可用性。

高扩展

扩展性应该总体分两个方面描述，横向扩展和纵向扩展。

横向扩展

个人认为，横向扩展可以理解为 “集群化”，将当前使用的底层资源，以同样的规格进行“复制”，从而使资源成倍的增长。当下云时代的容器化，可以算是横向扩展能力的终极表现。服务要具备良好的横向扩展的能力，最好有以下特点：

1. 无状态化。所有数据、逻辑不依赖本地。
2. 存储的有效拆分。按照业务逻辑垂直拆分表，水平拆分、分库分表。
3. 使用分布式配置中心进行配置。
4. 容器化。

纵向扩展

纵向扩展可以理解为，升级机器，把原来奔腾处理器、512M内存的服务器，升级为至强处理器，128G内存的服务器。这个对服务本身对于算力资源是有要求的，服务本身算力不行，并发做的不好，再大的CPU、再大的内存也利用不起来。

高性能

高性能核心可以分为并发、缓存、预热

并发好理解，充分利用现代处理器甚至是GPU异构处理器多核并发的能力。在服务内使用高并发的框架同时处理海量请求。并发要注意并发安全问题。

缓存，是对热点数据的尊重，是二八定律在计算机领域的体现。计算机本身硬件数据存储的设计就是多级缓存模式的，从慢到快分为硬盘、内存、多级高速缓存、寄存器。服务使用缓存的姿势，可以有内存缓存、分布式缓存（redis、memcache）、CDN等。

预热，在服务正式提供服务之前，冷启动之后，进行系统预热，从而使服务正式提供服务时，已经过了“磨合期”。常见的方式有压测预热、接口覆盖调用、流量逐步放大等。

可观察

可观察性（Observability）在敏捷开发，DevOps（开发运营），SRE中相当重要。另一方面，其对于老板的重要程度也特别高。领导层对于系统的认知除了亲自体验产品、查看用户反馈，剩下最重要的途径就是通过系统的各项指标。比如服务的SLA、性能数据、底层资源使用率等来衡量公司是否在低成本、高效率、高稳定的为用户提供服务。

后台架构拓展内容

软件架构模式

软件架构入门 - 阮一峰的网络日志

大型网站技术架构演进 

​​​​​​​10张图带你了解后台服务架构演变_极客猴的博客-CSDN博客

 服务发现

百度安全验证​​​​​​​

 架构定义

架构基本概念和架构本质 - samdyli - 博客园

引用

https://zh.wikipedia.org/wiki/%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84