大家好，我是消失了一个年假的不愿意透露姓名的神秘虾神，这是癸卯兔年虾神的第一个系列，聊聊GIS中的架构设计，不过你如果是做其他架构的也差不多……总之是架构是虾神的本职工作之一，那么培养更多的架构设计者和爱好者，也是虾神的本职工作。
恩，拜个晚年，应该还不算晚……

像虾神这种的师傅（不是所有年纪大的人，都有资格叫做大叔的……想要成为大叔，首先得有钱……类似虾神这种的中年人，通常只会被叫做“师傅”……）一听到“三高”这种体检报告上面的专用词，就不由会哆嗦一下……

不过我今天要说的不是体检报告，而是系统架构设计上的三个常用的概念：

• 高性能：指的是处理一件事务的速度更快，所消耗的资源更少，例如写一条比较优化的SQL语句，用更少的时间从数据库中检索出符合条件的数据。
• 高并发：指的是能同时正确的处理多个请求，例如有几千甚至几万人同时来访问我们提供的网站和服务，我们都能够正确的提供访问，这就是高并发。
• 高可用：指的是减少停工的时间，保证服务的持续可用，例如我们的服务与应用能够保证7*24小时不间断的提供服务，而且能够在出意外故障的情况下，也通过冗余设计来保证服务不中断。

这三者的概念迥然相异，却又相辅相成，正如你不能用高性能来描述高并发一样，但是在某些情况下，高性能确又正好是高并发的必然条件之一。
下面我们来看看在架构设计中最基本的三高原则分别是哪三高，又是通过哪些指标或者信息来描述的：
首先在设计中，最重要的是要做到高性能——天下武学，无坚不破，唯快不破：

高性能，从大了看，可以是某个垂直具体事务的处理能力，比如一次查询，又比如一次计算，所谓的垂直，是指不涉及横向关联，或者出现资源有发生竞争这种阻塞、等待情况的一次整体功能的执行速度。
在程序功能上，高性能通常会在衡量一次用户交互的整体场景，如下所示：
这是一个前端通过输入用户名密码，获取登陆token的完整时序图，对于用户来说，从输入之后，按下登录按钮，到获取这个token，就是一次操作响应，整个操作响应的时长，就是红色框所标识的部分。

但是做为程序员或者架构师，要设计这样一个功能，就需要考虑后面的2-11个功能步骤，每一个步骤都可能对应了一个或多个功能（在代码里面就一个Method或者说是一个Function[很多编程语言里面，这两个玩意儿是同义词，但是近期主力研究rust，在rust里面，method和function是两个不同的东西，居然不是同义的……真是反人类啊]），而每个功能都会有一系列系统资源调用和执行开销，也就说，任何一个步骤都有优化和处理的余地与需求。

整体所有的步骤的耗时累加起来，就正好是一个完整的用户操作与响应。

高性能更多的时候，会体现在编码开发与程序逻辑设计上，反而在架构设计上并没有特别的突出，不过做为三高中，最基础的内容，没有高性能，基本上其他的也就无从谈起了，所以我一直认为，高性能是优秀设计的根基与底座。

高性能的指标衡量，一般有如下四个指标：

响应时间

通俗来说，就是所谓的速度，但是这个速度一般在软件设计的时候，会通过一个具体的指标来进行规定，而且在互联网时代，会有一个常见的标准：2/5/10秒原则。

也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。
当然，比起用户体验来说，计算机里面每一次操作，基本上都以毫秒来统计，这若干个毫秒组成的整体响应时间又会被无数个细节和意想不到的问题所干扰，特别是还有很多程序员和架构师们都无法控制的变量，例如网络信号，又例如硬件（服务器硬件，甚至有可能是用户访问设备）。
总之，响应时间做为一个硬性指标，在软件设计阶段就会被提出来，而且一般不会有可商量的余地，2\5\10原则，做不到，直接就认为就是失败。

当然，从设计角度出发，这里我们还要考虑一个使用频率的概念。

例如，安装操作系统可能要1个小时，我们为什么觉得这很正常，因为我们要很久才装一次系统，如果系统使用得当，可能一个系统用几年不用重装，但是如果系统上装个小软件，比如那种几乎天天都要更新的手机APP，而每次更新都要一两个小时，那我们一定是无法忍受的。
而对于一个税务报账系统，假设该系统的用户每月才使用一次，一次花费3小时进行数据的录入，当用户单击“提交”按钮后，即使系统在10分钟后才给出“处理成功”的消息，我们也觉得是可以接受的。

因此，在进行性能测试与设计时，“合理的响应时间”更多的要取决和考虑于用户的需求与预期，而不能依据设计人员和测试人员自己设想来决定。

吞吐量与效率

吞吐量指的是系统每秒能够处理多少条信息，用吞（输入）和吐（输出）来形容，也算比较形象了，因为我们每个操作，一般来说都是独立的，例如登录这个操作，A在请求的时候的所有流程，B请求的时候，也是一样的流程，而且二者之间的执行可以完全不相互干扰或者相互依赖，这样系统的吞吐量就可以通过平行扩展来得到保证。通俗来说，就是我们可以用多台服务器组成的集群来提供更大的吞吐量。

吞吐量与效率一般通过TPS与QPS来体现：

TPS和后面的QPS这两个概念，在很多文章和说明里面，把二者进行通用描述。不过从系统架构上来说，TPS（Transaction Per Second：每秒通过事务数）更贴近于软件程序处理的范畴，因为在一些系统里面，还是有一些事务是不用通过数据库的，比如一些计算类型的任务。
一般说来，TPS可以做为吞吐量的一个衡量指标，这个指标越大，说明系统的吞吐量越大。

QPS，即每秒查询事务数（Query Per Second），这个指标在很多三高系统架构中被视为核心指标，对比TPS来说，QPS更贴近数据库，而业界有一大部分软件设计，都是围绕着数据库为核心来做系统设计和架构的（也就是我们经常说的CRUD系统）。这个指标也可以被认为是服务器（通常是数据库服务器，当然可能是其他的服务器，如redis这种缓存服务器，也可以是MinIO这种文件服务器、或者是elasticsearch这种全文检索服务器）的核心性能指标。

有效资源利用率

有效资源利用率（efficient resource utilization）通常指程序组件对系统资源的占用程度，理论上来说，消耗的资源越少，则设计越优秀。
这个指标在很多时候，在一些主流架构师的设计中，不管是有意还是无意，都被忽略掉了……因为不管是Web开发最主流卷王之王Java，还是前端独苗Javascript，都是吃内存的大户……俗话说得好：Java的性能是无穷的，只要你内存足够大。
所以，在架构师设计中，用了Java，用了Javascript，就自然忽略掉了这个指标。
但是如果有可能，我们当然是希望这个指标越优秀越好，那么选用一门好的编程语言，有时候也是有必要的：如下所示，这是2022年的最新语言基准测试：

（如果有可能，可以选用一门好的编程语言：例如Rust或者go……好吧，虽然我近期在研究Rust这个东西，但是我不是Rust传教者，我只是觉得这玩意儿和Python一起用特别爽，这个话题以后再说，but，Python一如既往的拉胯啊。不过转念一想，性能和可用有时候也是需要平衡的，Python虽然慢，但是写起来快啊……我不缺资源的情况下，我一天的工作量，你得写一周，恩，还是人月费用更贵）

比如我们选用Rust来替代所有的Java，从速度上看，可以提升约2倍，而从内存上看，可以减少4倍，综合下来，甚至可以节约二分之一到四分之三的服务器资源……单个系统可能看不出来，但是类似提供云服务的厂商，或者租用云服务器的庞大系统，每年就能节约一笔不小的开支。
随着云服务模式做为基础实施的逐步铺开，未来会有越来越多的系统会上云，那么很多时候，考虑这个指标，就与考虑成本划上了等号。

（待续未完）
GIS与三高架构设计是虾神去年在公司内部做的一系列内部讲座，全部的PPT和资料都已经准完了，今年将全部转换成文章，大概每周一篇，类似今天这样的篇幅，整体将在20-30篇左右，保证不烂尾。
希望广大同学点赞、在看、收藏、转发。