Web服务端软件的服务品质概要

软件品质概述

---

提供一样功能、产品和服务的服务者中， 竞争力来自功能的多样化和服务品质的差别化， 不管是个体、企业仍是国家。

• 这里的服务指功能、产品的实现程度和处理能力，以及研发/客服提供的技术支持程度（7*24, 随时响应, 沟通便捷，快速解决，舒适提示，有效指南等）。

• 从某种意义来讲， 一切皆服务。 功能和产品只是形式， 服务才是本质。服务响应某种需求从而具有存在价值。个体、企业为社会提供某种类型、某种程度的服务，并得到相应回报。

程序员提供的服务是，在特定的工做环境和企业文化中，运用可用的资源以及本身的知识、技能、经验、时间、精力、资源，在适当可接受的开发成本下，经过将现实问题构造和组织成正确的逻辑流而得到问题的解决并持续维护的能力程度。

• 这种能力程度既包括服务能力自己，也包括经过这种能力所创造的服务的能力。 服务能力自己主要包括： 精通特定语言、技术、平台、架构等的技术深度； 组合技术、产品、运营、服务、商业的综合认知广度；具有多样化技能（开发、写做、外语、沟通、组织、谈判等）；作事的能力素养，耐心、专一、缜密、魄力、幽默等； 具有非技术方面的特长，好比体育、音乐、文学、艺术、设计等。 经过这种能力所创造的服务， 一般是指软件、产品或服务。

每次解决用户最关心的前三个问题， 不为无关痛痒的事情浪费时间、精力和资源。

• 首先是功能与服务，功能与服务是核心，是存在的价值；
• 其次是设计，设计使功能与服务更加突出具备吸引力，更好的使用品质；
• 接着是成本和传播。保证优秀功能和设计的基础上下降资源时间和人力成本，同时良好的传播和使用让边际成本更低。

如何保证服务端开发的功能和服务达到应有的品质呢？

1. 明确须要达成的品质； 知道作什么以及如何作；
2. 将服务品质尽量量化并进行测量，作到服务品质透明化；
3. 更倾向于情感因素的服务品质，采用情感化方法处理。不在本文讨论范围内。

基本品质属性

---

正确性

软件是否正确实现了指定的功能， 知足客户的多样化须要。

• 绘制业务流程图、子系统交互图，遵循意图导航编程方法，经过分解、实现和链接若干紧密联系的逻辑单元而实现。
• 在内部实现上，是数据记录是否正确完整地构造、存取或销毁，且没有产生脏数据和无效数据【内部品质】。
• 须要创建功能实现的整个流程环路，对其中的全部细节知根究底，对交互的外部系统提供的相关服务也了如指掌。
• 量化： 业务数据是否合理的存取；若涉及多个子系统，则须要保证数据的一致性。
• 相关建议：

1. 沟通， 准确理解需求、场景及业务流；
2. 仔细挑选开发使用的工具箱、库与框架；
3. 经常使用子任务使用公认主流开发库并仔细测试；
4. 完整理解API， 包括其功能、原理、适用场合与局限性；
5. 编写类/方法/函数时注明使用契约及特殊处理；
6. 每一个类/方法/函数各司其职，相互协做。

性能成本

软件在指定时间和可用资源的前提下实现功能和服务的响应能力和请求处理能力。 须要有偏差范围的测量或估算。

• 构造单个请求测量运行时间和响应时间；构造大量并发请求测量吞吐量。
• 可参考 SLA (服务等级协议)。 程序的执行效率应当在可接受的开发成本下达到最佳。
• 这就是说，在 "开发功能所须要的时间和资源成本" 与 "最终实现的服务可以提供的品质" 存在一个权衡。
• 通常来讲，品质越高的服务所须要的时间和资源成本越高；无止境追求更高效率而不计成本和服务目标是不可取的。
• 比较理想的状况是： 经过适量改进、技术革新、管理改善等，可使得花费较少的时间和资源成本可以得到更高的服务品质。
• 量化： 运行时间、 所需的存储资源（数据库记录数、KV 数、缓存、文件）、 响应时间、吞吐量/并发能力（QPS, TPS, UPS）。
• 相关建议：

1. 大数据量结果集使用多线程技术获取子集并汇总；
2. 多IO任务使用异步方式来处理；
3. 耗时长的任务进行分解/并发/异步处理；
4. 避免没必要要的重复建立/计算开销；
5. 耗内存的大对象的延迟建立与复用；
6. 耗时长/频繁读操做适当利用缓存；
7. 短时操做控制在 0.5-1s 内， 长时操做采用“异步+消息通知”模式；
8. 测量时间，对热点区域进行适宜程度的优化；
9. 测量和改进响应时间与吞吐量， 使之达到良好的平衡；
10. 使用更好的硬件提高性能；
11. 减小启动加载组件，按需加载和缓存；
12. 使用异步模式逐步加载与展现；
13. 加载与执行分离；

健壮性

软件应对错误的能力。可以在非预期环境降级运行，在预期环境可以捕获全部的错误条件（前提不符合、非预期输入、脏数据等）和异常状况并给出合适的返回信息。

• 对于前端交互而言，须要友好容易理解的提示信息； 对于后台服务而言， 须要规范的错误码和错误消息。
• 软件健壮性的提升须要大量的错误检测，容易致使维护性下降。最好将错误检测从主业务流程中抽离出来，创建可复用的检测库函数。
• 建议先创建正确完整的业务主流程，而后对于主流程的每一个环节进行推敲，找出各类错误场景并进行处理。
  
• 量化： 错误场景测试用例数；覆盖场景数。
• 相关建议：

1. 错误码和错误消息使用配置文件，与代码分离；
2. 不一样类型的参数检测使用不一样的参数验证器（一般是正则表达式）;
3. 使用全局统一的错误检测函数尽可能在一个地方集中检测错误。
4. 细分应用中出现的各类异常并进行不一样的处理；
5. 在系统底层处理可以处理的异常， 没法处理的使用异常转译传给顶层；
6. 在系统顶层统一处理各类应用异常并返回友好提示；
7. 提示和异常消息放置在配置文件，与代码分离；
8. 错误处理全局框架。 `

易追踪性

程序运行过程当中输出适量的日志信息，便于追踪程序执行状态，快速排查错误【内部品质】。

• 识别业务流程的关键路径和关键状态，记录其运行时状态便于分析。
• 须要格式良好规范的适量且关键的 INFO 日志和 Error 日志。我的认为 DEBUG 日志能够经过提高代码质量来消除其必要性。
• 量化： 排查、定位每一个问题的所需时长。

易测试性

主要是单元测试、自动化功能测试和性能测试。 单元测试和功能测试保证正确性，性能测试保证效率【内部品质】。

• 单元测试要求在开发过程当中尽可能编写具备单一职责的短小方法、类；代码对象越小，单元测试所发挥的做用越大。
  
• 功能测试要求针对具体使用场景设计有效的测试用例、测试计划和测试执行。
• 性能测试要求对业务处理所需的时间和资源进行测量，给出最佳值、最差值和平均值。至少要对运行时间进行测量。
• 量化： 业务方法的测试覆盖度、代码行、分支覆盖程度、测试用例集合、性能测试报告。

安全性

避免泄漏重要、敏感、隐私信息； 保护业务和数据不受非法访问、非受权访问的破坏； 追踪系统访问日志。

• 常见的方法有敏感信息识别和屏蔽、访问受权机制、 访问日志审计、代码漏洞防备。
• 相关建议：
  

1. 用户角色与权限分级；
2. 只读与操做权限分离；
3. 机密数据加密保护/权限控制/操做限制/身份认证；
4. 权限申请加入审批流程制度；
5. 记录请求日志与用户操做日志；
6. 请求链接进行加密；
7. 避免显示请求 URL；
8. 防止注入攻击，识别非法请求模式。

可扩展性品质属性

---

可扩展性

• 相关建议：

1. 总体架构模块化设计， 组件服务化， 最小化公共服务接口；
2. 设计时老是考虑变化；
3. 使用配置参数， 避免硬编码；
4. 编写自包含、自封装、不修改外部状态的代码，最小化依赖；
5. 使用设计模式优化代码表达结构， 加强软件的“柔韧度”；
6. 文档化顺序与依赖关系， 按期整理、更新依赖关系；
7. 表达与执行分离， 使用领域语言/规则表达逻辑， 预编译规则， 规则的动态生成、配置和加载。

可复用性

要求软件中的函数、方法、类、库、模块、组件、框架等可以在同一工程或不一样项目或不一样产品中屡次使用，便于替换更新【内部品质】。

• 单一职责原则；
• 接口定义与设计正交；
• 对于每一个知识点、业务点和事实都有合理的抽象；
• 每一个业务方法最好不超过 60 行；
• 最起码要求是在同一工程中可以尽量复用， 避免重复代码段；
• 量化： 重复代码段数量； 函数、方法、类、库、模块、组件、框架的复用次数。

可维护性

要求软件容易理解、容易作出修改以知足新的需求，一般系统应具有模块化、高内聚、松耦合的特性【内部品质】。

容易理解

• 须要可复用性的支持，同时要求代码尽量具备语义与细节分离、自解释能力、适量注释、使用习惯用法。
• 语义与细节分离"指高层代码表达意图，低层代码呈现细节；"自解释能力"指代码经过合适的变量和函数命名可以望文生义；

• "适当的注释"须要注明代码意图及设计思路， 做为理解代码的有效指南；"习惯用法"是代码的经常使用模式，便于快速浏览和理解。

  容易修改

  须要快速定位一个功能服务所应对的代码集合，要求代码具备良好的组织和实现结构，避免对多个地方作出相同或相似的修改； 避免对原有总体设计作出大幅度修改。

• 请参考《敏捷软件开发：原则、模式和实践》一书，尽量知足五大设计原则(SRP, OCP, LSP, DIP, ISP)，实现“对修改关闭，对扩展开放”的境界。即：对于新需求的开发，尽量仅仅是增长代码，而不须要修改原有代码。

量化： 理解一个功能须要的时长； 修改或扩展一个功能须要修改的代码行。

全局性品质属性

---

稳定性

程序运行中可以始终如1、持续长时间地提供正确、一致性的服务。

• 要求程序可以合理地使用和释放资源，监控程序的运行状态并及时发现异常状况解决。
• 对于高并发场景， 须要采用合适的技术进行分流，及时处理或拒绝请求，避免由于资源消耗过快过大而致使服务崩溃。
• 量化： 程序的持续可用性时长； 高并发能力。
• 相关建议：

1. 确保软件的运行环境正常稳定，包括硬件、操做系统、依赖系统；
2. 软件可以有效应对环境波动（好比网络中断）而不至于终止；
3. 外部系统服务调用的影响局部化， 不影响总体运行；
4. 系统组件服务模块的影响局部化， 不影响总体运行；
5. 避免内存泄露，死循环，死锁等会致使程序崩溃的问题；
6. 批量资源释放问题要仔细检查，是否会由于错误或异常致使内存泄露；
7. 操做失败可回滚；

可靠性

服务在严重错误状况下的可恢复能力和可替换能力，避免单点故障，保证可用性，保证用户数据的正确性和完整性。

• 主要包括服务的冗余、容错、备份、监控、自检测和恢复机制。
• 量化： 服务发生错误时是否可用； 是否能够从错误中恢复。
• 相关建议：

1. 负载均衡避免单点故障；
2. 主备容灾应对紧急状况；
   
3. 高负载/性能测试；
4. 添加系统监控， 展现指定时间间隔内的系统各项指标/服务/资源的运行情况。

易用性

易用性是用户使用产品的难易程度的度量。 一般用于描述用户体验的前端领域。 不过服务端也有可用性的概念。

• 服务端的可用性， 深层次上体如今接口、库方法是否容易学习和使用、是否容易被滥用、误用；浅层次上体如今代码排版是否悦目易读、代码风格是否一致美观。
• 相关建议：

1. 知识与信息的准确性和丰富度，符合或超出指望；
2. 操做的引导设计、正确性与温馨度；
3. 外观与设计的实用美观，赏心悦目；
4. 使用动画或添加趣味内容消弱等待时间的影响；
5. 使用变化效果提示用户请求已经发送，正在处理。

弹性伸缩

服务能够经过简单地部署在更多机器上提高服务能力(吞吐量)，能够经过减小机器部署来下降成本。

• 须要从架构设计上进行支持。请求处理尽量是无状态的。
• 量化：并发请求处理量与机器数的比率。　
• 水平扩展： 增长多个逻辑单元资源并使他们做为一个总体在工做， 好比集群、分布式、负载均衡；
• 垂直扩展： 在同一个逻辑单位添加资源以增长容量， 好比增长CPU、内存、磁盘空间。

可移植性

软件可以在多种运行环境、平台上一致性地正确运行而只须要作出少许修改或无需修改。

• 使用可移植语言和平台、在实现功能和服务时尽量遵循标准接口和行为，减小非标准行为的使用；
• 在底层提供接口统一不一样平台的差别性；在高层使用统一接口进行处理，避免处理平台细节。
• 可移植性最好在系统构建之初进行考虑，好比初始采用 PHP， 后续移植到 Ruby, Python 或 Java 平台。
• 量化： 从一种语言移植到另外一种语言或从一个平台移植到另外一个平台所须要的代码行。
• 相关建议：

1. 使用抽象屏蔽不一样平台之间的差别；
2. 使用跨平台SDK；
3. 尽量遵循可移植的标准；
4. 尽量采用标准写法；
5. 响应式设计。

可运维性

服务发布后，管理大规模服务的运行、排查/诊断/解决问题的难度和速度、处理用户反馈的工做量。

• 服务发布后，可能产生的问题有哪些？ 怎么排查？ 服务的运行规模有多大？ 并发程度如何？
• 在服务开发上，须要避免的是低级问题的产生，减小低级错误致使的工做量；
• 对于疑难问题，则须要提供关键的日志信息/运维文档便于排查；
• 对于大规模服务的运行，一般的方法是监控、报警以及可视化。
• 量化： 参考运维的量化标准。

可定制／热升级

是否容易针对客户的特殊需求进行定制；服务升级时是否能够尽可能不影响到用户的正常使用。

• 相关建议：

1. 模块化应用程序和系统服务组件；
2. 每一个独立组件有一个标识， 标识其是否可显示/加载；
3. 经过配置文件指定启动或初始化时能够显示/加载的模块和组件；
4. 使用定时Job或有时限的缓存机制来加载配置文件；
5. 使用观察者模式检测配置的变化并从新加载配置到应用中；
6. 当检测配置变化时，能够发送外部命令给应用系统触发其从新加载配置；
7. 提供界面修改配置文件参数并实时更新应用和配置文件（可能有安全隐患）；
8. 使用全局单例管理者来负责根据配置文件的变化动态显示/隐藏和动态加载/卸载模块；
9. 使用策略模式灵活替换和切换具备相同功能的模块， 使用抽象抽取其公共使用接口。

互操做性

软件与其余系统交互的难易程度。主要包括通讯方式、版本兼容性。

参考文章

---

• 软件质量模型
• 实现软件架构质量属性的战术
• 可复用性：专题
• 可伸缩性最佳实践：来自eBay的经验
• 软件设计的可用性

转载请注明出处。谢谢！ :)