软件架构设计与原则

Posted 2021-04-10 Linyb极客之路

什么是架构？

• 部门的人力分配、 项目规划

• 建筑设计中楼层规划、功能性设施规划

• 城市的道路布局、功能性建筑设计、娱乐设施设计

• 国家的城市规划、高速公路规划、高铁线路规划

Allis架构!!!

架构的本质

• 核心生命周期拆分之后主体不变的子生命周期

• 非核心生命周期:拆分之后主体改变的子生命周期

架构的本质在于不断拆分生命周期(树形结构)，使得业务可以做到空间上并行。拆出来的每一个生命周期都有自己的边界，不会影响到其他生命周期，各自的变化都在自己的生命周期内确定，即为高内聚。

软件架构

• 软件生命周期:软件开发生命周期+软件运行生命周期(软件访问、软件功能、软件监控)

• 目的:解决软件复杂度(高性能、高可用、可扩展、低成本、安全、规模带来的问题，将构建和维护系统需要的人力成本降到最低。

优秀软件架构三要素

• Firmness (稳定) : Achieve a satisfactory level of freedom from damaging failure.

• Commodity (实用) : Utillity to accomplish the tasks it is purported to be for.

• Delight (易用) : Pleasure in use.

“建筑(Solid、 Useful、 Beautiful)->软件(Firmness、 Commodity、 Delight)

架构流程

架构流程

1. 业务架构:俯视架构，包括业务规则、业务模块和业务流程。主要是对整个系统的业务进行拆分，对领域模型进行设计，把现实中的业务转化成抽象的对象。

2. 技术架构:剖面架构，是硬件到应用的抽象，包括抽象层和编程接口。技术架构和业务架构是相辅相成的关系，业务架构的每一个部分都有其技术架构，系统的架构需要先做好这两部分。

3. 数据架构:存储架构，主要指的是数据结构的设计。决定了应用数据源的特性，是业务架构和技术架构的基础。

4. 部署架构:拓扑架构，包括系统部署了几个结点、结点之间的关系、服务器的高可用、容错性、网络接口与协议等。决定了应用如何运行、运行的性能、可维护性、可扩展性等，是所有架构的基础。

5. 组织架构:团队架构，包括项目的组织形式、人员构成、职责等，是上面所有架构的保障设施。良好的组织架构能够保证其他架构的有效实施和推进。

架构随着业务、负载的变化需要不断的梳理和重构，推进架构的演进。

业务架构

• 业务执行是应用的核心模块，是应用的主要功能。

• 数据分析是应用的辅助模块，有助于对应用做数据驱动化研发、商业智能研究、改善用户体验。

• 系统管理是应用的基础部分，做好系统的部署、各项指标的监控、关键数据的备份等有助于应用快速迭代部署和稳定运行。

• 业务数据源、数据的规则引擎和分析规则支撑起了交互界面的呈现

• 基础设施、通用服务构建起了底层的业务逻辑

• UI和应用都属于应用层，即提供具体的业务实现。其中UI是视图层的主要表现形式。

• 应用和服务属于控制逻辑和访问通道，其中服务则是主要的业务逻辑所在，提供服务接口，供应用调用。

• 核心、驱动和数据构成了数据层，是对业务中所有相关数据的操作逻辑，是模型层。其中，核心提供内部接口，供服务调用。

架构随着业务演化，如:对于Web应用来说：单体应用>垂直分离->平台化->服务化

部署架构

• UI交互界面单独部署，包括Web、App等形式

• 应用单独部署为一个结点或者 集群

• 服务、核心以及驱动做为整体进行部署

• 数据源单独部署

简单的Web应用部署架构: LVS + nginx + Tomcat

数据架构

• 交互界面呈现出来的数据交互逻辑、数据流向决定了业务的主要数据设计。

• 原始的业务数据、日志和统计需要的数据支撑了数据分析需要的报表输出。

• 实时信息在一定的规则和状态机引擎下可以提供出实时状态监测等仪表盘功能。

充分理解交互Ul，需要知道哪些数据界面关联，哪些数据可以缓存。

数据的五个属性

• 访问频率:读写频率;只读且经常被访问的数据可以冗余多份

• 对一致性的要求:一致性要求高的数据需要严格保证准确性。

• 访问权限API设计中根据不同的权限暴露不同粒度的数据。PO->VO即是对同一事物在不同权限下的描述,

• 数据重要性完全不可丢失、允许部分丢失、只是缓存、无需保存

• 数据保密性内部可以明文、内部不可明文、可以对外公开

什么是架构师？

• 生命周期识别，合理拆分生命周期

• 识别问题和问题的主体，切忌把解决方案当问题，发现问题永远比解决问题更加重要!!

• 关注业务技术，保障业务增长

• OKR架构:负责关键技术的突破，解决技术可行性问题，拿出从0到1的那些关键结果

• 权责对等，保障架构执行! ! !

架构师的工作， 就是在黑暗与混乱里寻找形状，并制造某种色彩。架构设计的关键思维就是判断和取舍，程序设计的关键思维是逻辑和实现。

架构师必备素质

• 基础技术能力:精通某种技术，能够从本质上理解并能够触类旁通良好的性能优化能力，能够在应用上线前预估到可能出现的性能问题并给出解决方案;扎实的调试能力，不管是在代码开发阶段还是线上环境，在应用发生bug或者线上故障时，能够快速识别问题并解决。

• 设计能力:识别问题的本质，区分来自需求方的需求是伪需求还是真正的需求，避免把解决方案当做问题精通设计模式和各种技术架构，但又不滥用具有解耦系统的能力，使得系统之间松耦合，原来只能串行的任务可以并行开展。

• 技术选型能力:平等对待所有技术，只有合适与不合适，没有喜欢与不喜欢;了解主流技术的优缺点，能够辨别是否需要造轮子。

• 技术前瞻能力:能够预料到需求可能产生怎样的变化，做好前瞻性设计:能清楚地知道系统的瓶颈在什么地方，不断地定位技术难度、研发进度、性能、内存等各方面的瓶颈，不断调整骨干力量解决瓶颈，在风险爆发之前就消除隐患。

• 沟通能力与各种角色的同事做好沟通、理解各方的诉求。

• 管理能力:锦上添花的能力>项目管理和团队管理能力

架构六步思考法

试图将未知问题转化为已知问题，而不是创造新问题。

架构原则概览

合适、简单、演化

架构原则一1

• 避免过度设计:简单的架构就是最好的架构。最简单的方案最容易实现和维护，也可以避免浪费资源，但方案中需要包括扩展。此外，架构不是一成不变的需要随着业务的发展而演进。

• 冗余设计:对服务、数据库的做结点冗余，保证服务的高可用。通过数据库主从模式、应用集群来实现。

• 多活数据中心:为了容灾，从根本上保障应用的高可用性。需要构建多活的数据中心，以防止一个数据中心由于不可控因素出现故障后，引起整个系统的不可用。

• 无状态设计: API、接口等的设计不能有前后依赖关系，一个资源不受其他资源改动的影响。无状态(不需要读写本地设备数据)的系统才能更好地进行扩展。如果非得有状态，则要么客户端管理状态，要么服务端用分布式缓存管理状态。

• 可回滚:对于任何业务尤其是关键业务，都具有恢复机制。可以使用基于日志的WAL、基于事件的Event sourcing等来实现可回滚。

• 可禁用/自我保护:具有限流机制，当上游的流量超过自身的负载能力时，能够拒绝溢出的请求。可以通过手动开关或者自动开关(监测异常流量行为)，在应用前端挡住流量。此外，永远不要信赖第三方服务的可靠性，依赖于第三方的功能务必有服务降级措施以及熔断管理。

架构原则- 2

• 问题可追踪:当系统出现问题时，能够定位请求的轨迹、每一步的请求信息等。分布式链路追踪系统即解决的此方面的问题。

• 可监控:可监控是保障系统能够稳定运行的关键。包括对业务逻辑的监控、应用进程的监控以及应用依赖的CPU、硬盘等系统资源的监控。每一个系统都需要做好这几个层面的监控。

• 故障隔离:将系统依赖的资源(线程、CPU)和服务隔离开来能够使得某个服务的故障不会影响其他服务的调用。通过线程池或者分散部署结点可以对故障进行隔离。此外，为不同的用户提供单独的访问通道，不仅仅能够做故障隔离，也有利于做用户权限控制。

• 成熟可控的技术选型:使用市面上主流、成熟、文档、支持资源多的技术，选择合适的而非最火的技术实现系统。面对自研和开源技术的选择，如果功能需求契合度很高，那么选择开源即可;如果开源技术是需求的子集或者超集，那么要衡量吃透这个开源技术的成本和自研的成本那个高。

• 梯级存储:内存->SSD硬盘->传统硬盘>磁带，可以根据数据的重要性和生命周期对数据进行分级存储。

架构原则- 3

• 缓存设计:隔离请求与后端逻辑、存储，是就近原则的一种机制。包括客户端缓存(预先下发资源)、Nginx缓存、本地缓存以及分布式缓存。

• 异步设计:对于调用方不关注结果或者允许结果延时返回的接口，采用队列进行异步响应能够很大程度提高系统性能;调用其他服务的时候不去等待服务方返回结果直接返回，同样能够提升系统响应性能。异步队列也是解决分布式事务的常用手段。

• 前瞻性设计:根据行业经验和预判，提前把可扩展性、后向兼容性设计好。

• 水平扩展:相比起垂直扩展，能够通过堆机器解决问题是最优先考虑的问题，系统的负载能力也才能接近无限扩展。此外，基于云计算技术根据系统的负载自动调整容量能够在节省成本的同时保证服务的可用性。

• 小步构建和发布:快速迭代项目，快速试错。不能有跨度时间过长的项目规划。

• 自动化:打包、测试的自动化称为持续集成，部署的自动化称为持续部署。自动化机制是快速迭代和试错的基础保证。

架构原则可扩展

• X轴，水平复制或克隆，面向目标，如数据库读写分离、复制表、replication等， 将单体应用或者以来的服务做冗余，通过负载均衡提高系统负载能力。高可用

• Y轴，面向功能/服务，如垂直应用、分布式服务等，就是将单体应用根据功能拆分成小的应用或者服务。垂直扩展

• Z轴，面向资源，如数据库水平分库，对资源做分片，将压力分散到不同的结点上。水平扩展

可扩展方案原则: 20倍设计、3倍实施、1.5倍部署(DID) 。

系统响应性能提升五板斧

• 异步:队列缓冲、异步请求。

• 并发:利用多CPU多线程执行业务逻辑。

• 就近原则:缓存、梯度存储。

• 减少1O ;合并细粒度接口为粗粒度接口、频繁的覆盖操作可以只做最后一次操作。这里一个需要特别注意的地方:代码中尽量避免在循环中调用外部服务，更好的做法是使用粗粒度批量接口在循环外面只进行一次请求。

• 分区:频繁访问的数据集规模保持在合理的范围。

数据设计Tips

注意存储效率

• 减少事务

• 减少联表查询

• 适当使用索引

• 考虑使用缓存

• 避免依赖于数据库的运算功能(函数、存储器、触发器等)，将负载放在更容易扩展的业务应用端

• 数据统计场景中，实时性要求较高的数据统计可以用Redis;非实时数据则可以使用单独表，通过

• 队列异步运算或者定时计算更新数据。此外，对于一致性要求较高的统计数据，需要依靠事务或者定时校对机制保证准确性。

• 索引区分度法则:辨识度超过20%的属性，如果有查询需求，就应该建立索引。

• 对于数值型数据，可以使用保序压缩方式在保证顺序不变的前提下减少字符串长度。如:进行36进制转化即一种保序压缩方式。

• 大量数据的去重计数如果允许误差可以选择基数估计算法(Hyperhyperlog、 Loglogcount) 或者布隆过滤器。

• 数据服务之间的传输(如消息队列)保障语义包括: At most once、At Lease once、Exactlyonce。其中前两者比较好实现，而Exactly once必须要下游支持，通过下游业务对数据做去重处理或者本身就具有幕等性来实现。如:使用数据库的唯一ID作为表的唯一标识保障重复数据只处理一次。这在使用类似消息队列的场景中要特别注意。

架构可用性隐患分析-FMEA方法

Failure mode and effects analysis, 故障模式与影响分析->全面分析系统的可用性

• 给出初始的架构设计图。

• 假设架构中某个部件发生故障。

• 分析此故障对系统功能造成的影响。

• 根据分析结果，判断架构是否需要进行优化。

FEMA方法分析表格

• 功能点用户角度

• 故障模式:系统会出现的故障，量化描述

• 故障影响:功能点会受到什么影响

• 严重程度对业务的影响程度。致命/高/中/低/无

• 故障原因:故障出现的原因

• 故障概率:某个具体故障原因发生的概率

• 风险程度:综合考虑严重程度和故障概率，严重程度X故障概率

• 已有措施:故障发生时的应对措施。包括检测告警、容错、自恢复等。

• 规避措施降低故障发生概率而做的事情，包括技术手段和管理手段。

• 解决措施:此问题的彻底解决办法

• 后续规划:后续改进计划，包括技术手段、管理手段，可以是规避措施，也可以是解决措施。风险程度越高的隐患解决的优先级越高

架构重构

• 确定重构的目的和必要性:为了业务需要;有无其他备选方案

• 定义“重构完成”的界限

• 渐进式重构

• 确定当前的架构状态

• 不要忽略数据

• 管理好技术债务

• 远离那些虚荣的东西

• 做好准备面对压力

• 了解业务

• 做好面对非技术因素的准备

• 对于代码质量有所掌握

其他

• 讨论技术方案时，以是否合理为依据，而不要以工作量少为依据。

• 脱离业务谈架构就是耍流氓。

• 软件架构"4+1"视图模型:逻辑视图、开发视图、过程视图、物理视图+场景视图

• 系统设计文档模板;系统架构设计

• 技术调研文档模板:技术方案调研输出