系统设计原则及技术指标

系统-技术设计原则

好系统是迭代出来的：

先解决核心的问题，预测未来可能出现的问题。第一版1000人，所以单机。不要过度复杂化系统，先行的规划和设计，对现在的问题有方案，对未来系统有预案。

优先核心业务功能开发： 系统的初期，以核心业务为主，快速上线，占取市场份额，等待用户及市场反馈，及时调整需求进行项目迭代，不要一开始就想开发一个淘宝或者京东，也许你可以开发出来，但是市场份额已满，到头来一场空。

不要过度复杂化系统： 不要为了用某项技术而使用，某项技术的使用是为了应对业务增长带来的系统瓶颈问题，例如一个简单的OA系统，你非要使用微服务、分布式架构、亿级流量缓存，除了增加了开发、运维成本，还要应对开发过程中的种种问题，“不是贵的才是最好的，适合自己才是最重要的”。

先行的规划和设计： 对将要做的系统有一个基本的了解，可以通过产品运营了解大概的用户量、请求等系统指标信息，并以此为基础对服务器资源、网络资源、系统架构有一个基本的规划和设计。

对现有的问题有方案，对未来可能出现的问题有预案： 针对已上线或测试阶段发现的问题有解决方案，并对未来可能出现的问题有预案，例如秒杀场景下要预测大量请求进来对系统的压力（服务器、网络、存储等），并做好应急方案，防止系统崩溃。

无状态原则：

无状态服务（stateless service）： 对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。

有状态服务（stateful service）： 则相反，它会在自身保存一些数据，先后的请求是有关联的。

两者对比 ：

项目	有状态服务	无状态服务
HA	负载均衡服务	负载均衡服务
数据同步	需要同步	无数据同步
资源消耗	消耗内存资源保存数据消耗带宽进行数据同步	无内存消耗无带宽消耗
部署发布	部署服务还需要额外的数据同步操作，有冷启动的问题	直接部署上线即可使用
故障转移	可能存在数据同步不完全，丢失数据	负载均衡失效转移，无数据丢失

总结两者的区别： 因为无状态原则的特性，让RESTful在分布式系统中得到了广泛的应用，它改善了分布式系统的可见性、可靠性以及可伸缩性，同时有效的降低了Client与Server之间的交互延迟。无状态的请求有利于实现负载均衡，在分布式web系统下，有多个可的Server，每个Server都可以处理Client发送的请求。有状态的请求的状态信息只保存在第一次接收请求的Server上，所以后来同一个Client的请求都只能由这台Server来处理，Server无法自由调度请求。无状态请求则完全没有这个限制。其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地交由另一台可用Server来处理，而有状态的请求则会因为存储请求状态信息的Server宕机而承担状态丢失的风险。Restful风格的无状态约束要求Server不保存请求状态，如果确实需要维持用户状态，也应由Client负责。例如：
使用Cookies通过客户端保持登陆状态：
在REST中，每一个对象都是通过URL来表示，对象用户负责将状态信息打包进每一条信息内，保证对象的处理总是无状态的。在HTTP服务器中，服务器没有保存客户端的状态信息，客户端必须每次都带上自己的状态去请求服务器。客户端以URL形式提交的请求包含了cookies等带状态的数据，这些数据完全指定了所需的登录信息，而不需要其他请求的上下文或内存。
传递User credentials是Restful，而传递SessionID是Un-Restful的,因为session信息保存在服务器端。
无状态请求：Server不保存任何请求状态信息，Client的每一个请求都具有User credentials等所需要的全部信息，所以能被任意可用的Server应答。
有状态请求：Server保存了Client的请求状态，Server会通过Client传递的SessionID在Server中的Session作用域找到之前交互的信息，并以此来实现应答。所以Client只能由某一个Server来应答。

拆分原则：

为什么要拆分： 用户量大了（并发上来了）、业务复杂了（需要快速迭代）、可配置资源增加了（运维成本）。

拆分的作用： 高内聚、低耦合。

拆分维度：

系统维度：可拆分为商品系统、支付系统、用户系统、订单系统等，具体拆分为几个系统需产品经理确定或项目经理决定。

功能维度：基于系统维度进行二次拆分，例如用户系统拆分为用户会员系统、用户积分系统、用户中心等

读写维度：读写比例特征进行拆分。读服务（多级缓存）、写服务（分区、分库）

切面：cdn。对系统功能进行详细的梳理。aop。

模块：基础架构组封装二方库。数据库连接（支持多数据源、多种数据库）、分库分表表模块（动态配置接入）、综合消息队列（统一配置，兼容主流消息队列）、支付渠道接入（多渠道路由）

服务化原则：单节点到节点集群，节点维护困难，需要对服务进行自动注册及发现（服务治理），高并发下对服务进行限流、熔断、降级、隔离、恢复。

系统-业务设计原则

防重原则，幂等原则：

防重一般伴随着幂等一起出现,防止重复提交导致的幂等性问题。

客户端防重：按钮置灰、唯一标志

服务端防重：锁、黑名单、限流

模块复用原则：

重构时机：当部分代码在多个地方出现，或者你有想要拷贝的欲望时，证明需要重构次部分代码了。

重构的作用：代码可读性、可维护性提升、个人能力的体现。

可追溯原则：

一般情况下表现为记录日志，任何问题有据可查，有据可依，能快速发现问题并定位问题（甩锅锅）。

反馈原则：

给调用方一个明确的反馈。

A：用户名不存在，账号密码错误，用户无权限。

B：登录错误，请重试。

备份原则：

代码备份：Git、GitLab、代码分支
数据备份：运维备份（数据库、存储、操作记录）
人员备份：不因某功能负责人员缺席而导致功能无法正常运行导致项目停滞。
定期CodeReview
项目开发规范（阿里开发规范：泰山终极版）
项目文档

软件质量衡量标准

晋升：总结过去，展望未来。
标准：ios/iec等标准
功能性：满足现有业务功能需求。
效能：投入与产出。
系统兼容性
易用性
可靠性：容错、可恢复。
安全
可维护性
可移植性

系统衡量指标

吞吐量：

单位时间内，能接受和发出的数据量。业务、配置。

TPS: Transaction Per Second，事务：请求，处理，响应。

QPS： Queries Per Second

TPS和QPS： 之间的换算关系，必须由指定的业务场景来定。

TPS与QTP的区别：

TPS：

Transactions Per Second:每秒事务数

具体事务的定义，都是人为的，可以一个接口、多个接口、一个业务流程等等一个事务是指事务内第一个请求发送到接收到最后一个请求响应的过程，以此来计算使用的时间和完成的事务个数

如果一个接口定义为一个事务，事务包含以下三个过程：

1.向服务器发送请求

2.服务器自己内容处理（应用服务器、数据库服务器等）

3.服务器返回结果给客户端

如果每秒能够完成N次这三个过程，则tps为N

如果多个接口定义为一个事务，则会重复执行上述步骤，完成一次所有的接口请求，算作为1个tps

QPS：

Queries Per Second：每秒查询率

一台服务器每秒能够响应的查询次数（数据库中每秒执行查询sql的次数），这不能描述增删改，一般不使用QPS作为系统性能指标

区别：

如果对一个查询接口（单场景）进行压测，该接口不会再去请求其他接口，则tps=qps，否则不等于

如果为容量场景，n个接口都为查询接口，接口不会再去请求其他接口，qps=n*tps

在jmeter的聚合报告中，Throughput是用来衡量请求的吞吐量，即tps

并发数：

并发用户数： 有一部分用户使用业务，另外一部分用户挂机，没有具体操作。

并发连接数： 用户和服务器之间的连接。一部分连接在传输数据，一部分连接仅仅连接而已。

并发请求数： 请求静态数据，有可能是写操作。

并发线程数： 系统内，并发的线程数目。

响应时间&平均响应时间：

吞吐量： 单位时间内，能接受和返回的数据请求量。看业务逻辑，看请求数据。

TPS： Transaction Per Second。每秒进行的事务的数目。（整体定义事务的请求、操作、返回）。

QPS：Queries Per Second。每秒查询量。

TPS和QPS的关系： 打开首页就是一个事务。由具体的场景来决定。一个完整功能。

平均响应时间： 响应时间（用户的角度）（请求发出，接受到响应，之间的时间）所有响应时间的平均值。

可靠性指标： 平均无故障时间。系统上线，到第一次发生故障，运行时间的平均值。

阿姆达尔定律：

加速比： 优化前的响应时间/优化后的响应时间。r。

增强比例： 某个模块的响应时间/总时间。 <=1，p。

整体系统的平均响应时间： t新 = t老时间 * ((1-p)+p/r)。

整体系统的加速比： 1/((1-p)+p/r)。

目的：优化 p值大的系统。加大r。