系统设计原则及技术指标

1 系统技术设计原则

好的系统都是迭代出来的

1. 优先核心业务功能开发

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

2. 不要过度复杂化系统

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

3. 先行的规划和设计

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

4. 对现有的问题有方案，对未来可能出现的问题有预案

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

无状态原则

1. 什么是有状态

   服务端保存用户登录状态，维护客户端会话。

2. 什么是无状态

   服务端不保存用户登录状态，不维护客户端会话。

3. 有无状态对比

   优缺点	有状态	无状态
   优点	服务端对登录状态可控	不存储登录状态；服务可伸缩
   缺点	服务端存储，增加了服务端压力；服务伸缩困难	登录状态控制困难

拆分原则

1. 为什么要拆分

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

2. 拆分的作用

   高内聚、低耦合。

3. 拆分维度
   1. 系统维度：可拆分为商品系统、支付系统、用户系统、订单系统等，具体拆分为几个系统需产品经理确定或项目经理决定。
   2. 功能维度：基于系统维度进行二次拆分，例如用户系统拆分为用户会员系统、用户积分系统、用户中心等
   3. 读写维度：读写比例特征进行拆分。读服务（多级缓存）、写服务（分区、分库）
   4. 切面：CDN、LVS、SLB，请求分流、限流、缓存等
   5. 模块：基础架构组封装二方库。数据库连接（支持多数据源、多种数据库）、分库分表表模块（动态配置接入）、综合消息队列（统一配置，兼容主流消息队列）、支付渠道接入（多渠道路由）
   6. 服务化原则：单节点到节点集群，节点维护困难，需要对服务进行自动注册及发现（服务治理），高并发下对服务进行限流、熔断、降级、隔离、恢复。

2 系统业务设计原则

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

1. 客户端防重（按钮置灰、唯一标志）
2. 服务端防重（锁、黑名单、限流）

模块复用原则

1. 重构时机

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

2. 重构的作用

   代码可读性、可维护性提升、个人能力的体现。 可追溯原则 一般情况下表现为记录日志，任何问题有据可查，有据可依，能快速发现问题并定位问题（甩锅锅）。 反馈原则 接口设计规范，语义明确，但隐私内容该做的处理还是要做。 备份原则

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

3 软件质量衡量标准

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

4 系统衡量指标

1. 吞吐量
2. 并发数
   1. 并发用户数

   用户在线，但不见得会访问系统。

   2. 并发连接数

   同用户在线，建立连接但不读写数据，基本系统无压力。

   3. 并发请求数

   大量请求瞬时到达服务器。

   4. 并发线程数

   并发处理业务。

3. 响应时间&平均响应时间