20250511-总结经验

一、SOA

1）过程：需求分析、系统设计、系统实现、构件组装、部署运维、后开发阶段。

2）特点：无状态、单一职责、明确定义接口、自包含、模块化、粗粒度、重用性、兼容性、互操作性、松耦合、策略声明。

3）标准：文档标准化、通信协议标准、应用程序、统一登记与集成、服务质量。

4）组成：UDDI、WSDL、SOAP、WEB Service。

5）应用：

        分析阶段：

                *单体应用：预约挂号系统是单体应用。

                *用例图：通过用例图分析需求。

                *类：医院、用户、订单、支付、三方服务等。

                *拆分：预测 系统用户超千万、万级并发、单服务器资源小、需要负载均衡，所以需要拆分。

                *性能可用性：添加缓存、负载均衡。

                *文档：需求规格说明书、需求约束。

        设计阶段：

                *模块UDDI、WSDL、SOAP、WEB Service的设计。

                *UDDI：1服务注册表。2重用nacos、Eureka。

                *WSDL：1参数、接口、协议、URI、请求方法。

                *SOAP：消息传递规范。（XML）

                *RESTful：轻量级通信。（XML、JSON、text）

                *WEB Service：1用例图划分。2通信图表示交互。3环调用问题。4负载均衡、集群、redis、ES。

                *文档：接口规范、开发手册、体系结构规格说明书、质量设计说明书。

                *设计模型：1状态图、活动图、序列图、通信图、时间图、交互概览图。2类图、对象图、构件图、部署图。

        实施阶段：实现、构件组装、测试、运行维护。

二、ABSD

1）过程：体系结构需求、体系结构设计、体系结构文档化、体系结构复审、体系结构实现、体系结构演化。

2）特点：体系结构驱动、自顶向下递归细化、功能分解、体系结构风格实现质量和商业需求、模版使用。

3）设计方法：采用视图视角描述架构；用例描述功能需求；质量场景描述质量需求；

4）应用

        **需求：1提高性能、可用性，系统需要能承载千万用户量，并发支持万级别，实现一年99.95%时间正常运行，系统需要提高运维能力以保证复杂场景的稳定运行；2预约挂号使用用例图表示功能需求；3类：医院、医生、科室、用户、订单、支付、三方服务等。4构件：机构、用户、订单、支付、三方服务等构件。5评审。

        **设计：1微服务、分层结构风格；2ATAM评估确定，微服务+微服务聚合器，使用微服务方式实现，再使用面向服务的开发方法定义微服务之间的交互，注册中心；3映射构件，机构、订单、三方服务开发，用户和支付复用，另增加Nacos作为服务注册与发现（中间件加进去提高可用性和性能）。4使用通信图表示构件间关系。5用4+1视图表示系统体系结构各个视角。6组织评审，分析师、架构师、测试、产品、项目经理、利益相关者，确定设计是否有风险、缺陷。（这个时候可以加上ES）

                分析构件间相互作用：问题-微服务循环调用，解决-微服务聚合器。

        **文档化：1背景使用文字，多图表示（注释），形成体系结构规格说明书；2非功能性需求 性能（<3s）、可用性（>99.95%/年），形成质量设计说明书，测试使用。

        **复审：找医院代表、系统工程师、项目经理、产品经理、利益相关者。风险：JWT鉴权，接口请求头中使用明文Token标识不安全，需要改变策略但迟迟没有解决；权衡：反向代理添加防黄牛，降低性能和可用性。

        **实现：编码、测试、部署，重用用户和支付需要Spring的架构升级，其他的使用新Spring架构开发，遵循能复用即复用的机会复用方式，获得构件后组装成预约挂号系统，通过jmeter测试通过满足高并发的要求，通过生产环境模型一周的运行轨迹也圆满的符合可用性的标准。

        **演化：收集用户评价，获得变更需求并归类，首先制定演化计划并评审，根据计划开发或适配构件，替换组装适配构件，更新体系结构的构件关系，然后进行测试，后评审发布阶段，最后得到演化后的系统。

                例：Easy Excel工具POI漏洞，升级3版本以上，经讨论优先级较高、不能影响用户使用，涉及订单服务的更新，更新测试，金丝雀发布，运行3个月后正式更新生产。

三、架构评估

1）目标：

        SAAM关注修改性、功能性、适应性、扩展性、移植性，通过场景分析验证架构是否满足系统需求，识别架构缺陷、风险点，支持架构决策。

        ATAM关注性能、可用性、修改性、安全性等，通过评估多个质量属性之间的权衡和优先级，核心：识别架构的风险点，支持架构优化，增强利益相关者协作。

2）质量属性：

        SAAM：修改性、功能性、适应性、扩展性、移植性等，单一质量属性；通过质量属性具体化为场景，评估体系结构满足特定需求的适应能力。

        ATAM：性能、可用性、修改性、安全性等，负载质量属性；通过分析多个质量属性之间的冲突和权衡，发现潜在的设计风险，并提供改进建议。

3）评估活动：

        SAAM：场景开发、架构描述、单个场景评估、场景交互、总体评估。（侧重场景驱动分析，方法简单、易于实施，适合中小型项目）

        ATAM：1描述阶段：描述ATAM、描述业务目标、描述架构；2调查分析阶段：提出架构方法、质量属性效用树、分析架构方法；3测试阶段：场景讨论与场景分级、分析架构方法；4报告阶段：整理手机资料、通知项目干系人；（强调利益相关者参与，确保结果的全面性和可靠性，适合复杂系统的评估）

4）应用

        ATAM：

                描述阶段：

                        描述ATAM：ATAM是基于场景的架构评估方法，通过评估多个质量属性，从冲突中权衡获得最优的架构，核心是识别风险点，提出改进策略；

                        描述业务目标：预约挂号目标是为用户提供一个稳定、实时的医疗服务平台，需要支撑名医抢号时期的压力；

                        描述架构：Spring框架，单体式架构、业务耦合、名医抢号时期系统出现卡顿、严重时崩坏、单台服务器资源使用猛增、黄牛抢号；

                调查与分析：

                        提出体系结构方法：微服务、分层结构风格。微服务：伸缩性、服务化、SpringBoot框架、服务注册表、小微轻松读专；分层结构：结构清晰/层次分明、层间解耦、SpringMVC框架、版本迭代、安全性高（向下访问）。

                        生成质量属性效用树：性能、可用性、安全性、可修改性。性能：名医抢号功能需要支持万级的并发；可用性：系统一年要99.95的时间平稳运行；安全性：需要预防黄牛抢号，提升抢号的公平性；可修改性：迭代每月一次。

                        分析体系结构方法：性能、可用性 > 安全性 > 可修改性。

                                首先，保障系统可用，再，保障系统的响应时间，平均响应时间<3s；

                                提高防黄牛策略：IP段黑名单、有效时间法、有效令牌法；

                                约定一个月迭代一次功能/优化。

                                风险点：业务耦合性太高，在名医抢号期间会导致其他业务功能吞吐量降低，影响用户体验；权衡点：拆分服务虽然提高了伸缩性，但是性能和维护性会下降；非风险点：反向代理添加防黄牛策略可能会过滤掉正常用户抢号。敏感点：选择HTTP协议、使用JSON轻量级数据格式、专有网络，可以提高系统沟通性能、安全性。

                                架构抉择：通过分析，分层结构虽然也能伸缩、扩展和易于学习，但是可用性和性能重要，且业务需要拆分开来，资源按需分配，微服务体系结构适合，容器化、服务注册发现nacos。

                测试阶段：

                        场景讨论和分级：邀请利益相关者，三方医院人员、项目经理、技术总监、产品、测试、架构师，讨论设计方案。提出循环调用问题，使用微服务聚合器，限制调用层级为两层。4+1视图。文档：体系结构规格说明书、质量设计说明书。

                        分析架构方法/测试架构：根据体系结构规格说明书部署系统，根据质量设计说明书评估可用性和性能指标。邀请更多的人评价系统，更新质量属性效用树，收集风险点、权衡点等问题，提出决策，最终确定了微服务架构的正确性。

                总结：

                        收集讨论过程中的质量属性效用树、风险点、权衡点、敏感点等，以及处理结果，再细化设计文档，通知项目干系人。

四、云原生

1）过程：系统架构设计的生命周期：需求分析-设计-实现-构件组装-部署阶段-后开发阶段；

2）特点：虚拟化、非功能委托、自动化、整合服务、随用随取；

3）原则：服务化、无服务器、服务网格、弹性、韧性、所有过程自动化、可观测性、零信任、架构持续演化。

4）模式：服务化、无服务器、服务网格、可观测、存算分离、分布式事务（XA/BASE/TCC/Sage/AT）、事件驱动架构。

5）介绍：

        服务化：接口约定定义彼此业务关系；标准协议确保彼此互联互通；领域模型驱动、测试驱动开发、容器化部署；提高代码质量和迭代速度；

        服务网格：将微服务之间的连接、安全、流程、可观测等通用功能下沉为基础设施，让应用于平台基础设施解耦；分离组件、安全策略、流量控制、微隔离；

        无服务器模式：部署从人工转到自动化；委托，不关心存储节点、操作系统、网络、计算机性能等；按需分配；自动扩展；高可用；快速部署；

        存算分离：云存储，暂态数据、结构化、非结构化数据；服务器无状态；

        分布式事务：

        可观测：

6）应用：服务化——存算分离——容器化——无服务器——服务网格——分布式事务

        Kubernetes：容器编排技术；服务调度；存算分离；

        Docker：容器化

        Prometheus：可观测；日志收集，ES、Logstash、Kibana

        服务化：微服务、HTTP、Nacos、Redis、Elastic search（分布式搜索和分析引擎）

        CICD：持续集成持续部署；

        自动化：Kubernetes自动拉起。

        分布式数据库代理：Cobar

        服务网格：lstio

五、特定领域软件架构DSSA

1）过程：领域分析、领域设计、领域实现；

        领域分析：领域专家、领域分析人员。目标获取领域模型，描述系统的共同需求。

        领域设计：领域设计人员。目标获取领域架构，满足被建模的领域需求。形成重用基础设施规约。要求领域经验的设计人员。

        领域实现：领域实现人员。依据模型、架构，开发组织可重用信息、软件可重用的实现。软件重用、再工程、领域经验的开发人员。

2）DSSA的建立过程：定义领域范围、定义领域特定元素、定义领域特定设计和需求约束、定义领域模型和体系结构、产生收集可重用产品单元。

3）特点：严格定义的问题域和问题解域、普遍性（用于领域特定应用开发）、对整个领域构件的组织模型的恰当抽象、【具备领域固定、典型、开发过程中重用的元素】。

4）应用：机构服务

        定义领域范围：确定需求、确定时间。医疗领域：生活中必不可少、公司对医疗有功底、邀请多个医院的技术专家。领域范围：创建医院、科室、医生，发放号源，单日预约抢号，检索定位，三方医院交互。

        定义领域特定元素：定义领域字典、领域同义词字典。医疗领域专家培训（机构概念、his代表医院、普通医生没有实体数据（排班）），建立领域词典（学习查询）。

        定义领域特定设计和需求约束：识别约束，记录约束对设计和实现造成的后果。基础功能实现，抢号的性能问题设计（缓存）、检索与定位设计、三方医院请求数据（缓存锁定号源）。抢号数据一致性问题（消息队列，异步通知抢号结果）采用BASE理论。

        定义领域模型和体系结构：产生体系结构，说明构成该模块的语法和语义。现有业务需求产生领域模型（4+1），根据需求采用微服务架构模式（服务化、复用性好、独立性），增加缓存（放号源）异步更新数据，最终一致性，消息推送。

        产生收集可重用产品单元：为DSSA增加构件，用来解决领域中的问题。（redis缓存、ES检索定位、极光消息推送中间件 + 异步线程短信通知抢号结果）

六、分布式

1）技术：CDN内容分发网络、反向代理、负载均衡、微服务、分布式缓存、分布式文件系统、主从复制/读写分离/分库分表、分布式数据库、NoSQL。

2）特点：资源共享、提高运算速度（分配运算任务）、高可靠性、通信方便快捷（网络互联）。

3）应用：

        CDN：结合 网络、连接、负载 合理分配最近的节点。解决拥堵、优化网络、降低延迟。

        反向代理：服务端、接收转发、转发一个服务器中、转发过滤、拦截器。 nginx + IP段黑名单/有效时间法/有效令牌法 算法；

        负载均衡：关注整体负载、转发策略、利用率、保证吞吐和响应速度。 nginx + 权重

        微服务：业务拆分、简化业务复杂性、提高开发/维护效率。 拆分、独立使用技术、独立扩展、小团队开发、容器化、机构中心自由伸缩、轻量级通信。

        分布式缓存：内存读写块、热点数据、持久化。 redis、存放号源、存放主页热点数据。

        分布式文件系统：分散存储、网络连接、分布透明性； HDFS/OSS、身份认证。

        主从复制/读写分离：主从、复制、读写分开； 主写从读、从同步、最终一致性。（提高吞吐量、降低并发延迟）

        分库分表：分库、分表； 业务分库、访问频率/范围分表。

        分布式数据库：分片分布地点、全局外模式交互、全局概念模式分片透明性； Cobar分布式数据库代理Mysql、业务拆分库、按城市存储分片数据；

        NoSQL：键值对、列族、文档、图形； ES搜索引擎、倒排索引、地理位置、距离算法；（医院信息）

七、软件设计方法

1）方法：结构化、面向对象、面向服务、构件化、原型、敏捷。

2）特点：

        结构化：1开发目标清晰化；2开发工作阶段化；3开发文档规范化；4设计方法结构化（自顶向下分解，自底向上实现）；5过程驱动；6应用场景：需求明确、变化少的中小型系统。

        面向对象：1对象为核心、封装/继承/多态；2场景：高复杂度、需求频繁变更的场景；3提高维护性、降低耦合。

        面向服务：1服务化、跨平台集成、异构系统整合、适合分布式架构需求；2场景：复杂业务、跨系统协作。

        服务化：为请求者提供需要，以独立服务为单元，使用标准化接口实现松耦合交互；

        构件化：1复用、标准化接口（接口规范/兼容/扩展）；2场景：快速迭代的通用功能开发、快速获得可运行的系统、低代码平台。

        原型：1快速验证需求、收集用户反馈、降低需求理解偏差；2用户深度参与、确保产品符合预期；3场景：需求不明确、频繁变更、创新项目；

        敏捷：1迭代交付、短周期、持续交付、快速响应变更；2团队协作优先、强调面对面沟通、减少文档依赖、提升开发灵活性。3场景：需求不明确、优先级动态调整的项目；

3）选型

        面向服务：服务注册表、服务化、微服务、粗粒度、轻量级通信。

        敏捷：沟通、简单、反馈、勇气；小小简单测试，40隐喻集体用户，计划重构，集成代码规范。

4）应用：面向服务 + 敏捷

        沟通：强调有效率的沟通。晨会汇报工作、周会总结经验。每人负责两个服务构件的开发（小团队），架构设计时医院、医生、科室合为一个服务，机构名称、his标识医院、普通医生属于弱实体。

        简单：简单设计，注重实现。HTTP轻量级通信、使用Swagger接口文档、编码注释（评审）、编码插件（0警告）、机会复用、CICD流水线、每个服务专一性。（名医抢号的缓存逻辑）

        反馈：团队间人员及时反馈。敏感点、权衡点、风险点、非风险点；代码规范咨询资深开发人员，代码评审不足之处反馈并提出解决方案；

        勇气：开发/重构期间，勇于抉择和实践。实践：名医抢号直接缓存、添加ES搜索引擎和位置定位、分布式部署Docker+k8s。

八、软件可靠性

1）技术：容错（N版本/恢复块/冗余）、检错（监控/告警/熔断/降级）、降低复杂度（系统结构/算法/圈复杂度/调用链的长短）、双机热备技术（双机热备/双机互备/双机双工）

2）模型：种子法、可靠性增长模型、系统结构分析模型、执行路径分析方法模型。

        可靠性度量指标：故障率、平均修复时间MTTR、平均失效等待时间MTTF、平均失效间隔时间MTBF、可靠度

3）开发期可靠性管理：

        需求分析：可靠性目标、影响可靠性因素、可靠性验收标准、初步的活动计划、收集可靠性数据规约、可靠性文档编写规约。

        概念结构设计：可靠性度量方案、可靠性验收方案、可靠性设计、整理可靠性活动计划、收集可靠性数据、确定后续活动计划、编写可靠性文档。

        详细结构设计：可靠性设计、可靠性预测、调整可靠性活动计划、收集可靠性数据、确定后续活动计划、编写可靠性文档。

        编码：编码、单元测试、修改问题、调整可靠性活动计划、收集可靠性数据、确定后续活动计划、编写可靠性文档。

        测试：集成测试、系统测试、排错、建模（用户看）、收集评价、调整可靠性活动计划、收集可靠性数据、确定后续活动计划、编写可靠性文档。

        实施：验收测试、排错、调整可靠性活动计划、收集可靠性数据、可靠性评价、编写可靠性文档。

        可靠性评价过程：可靠性建模、收集可靠性数据、可靠性评估预测。

4）应用：

        容错技术：冗余策略，服务、数据多份副本，保证安全性；1）服务最少两个副本运行、机构中心采用5个副本；2）数据库采用分布式的方式，通过业务分库分表，每个库都采用主从复制方式。

        检错技术：

                未发生的异常：我们采用了prometheus构建，采集系统状态、指标规则监控告警，短信、通信软件和邮件通知。

                已发生的异常：采用降级和熔断策略，降级：服务器>80%，离线计算业务自动从服务器上推出。熔断：请求错误率>60%，自动断开请求，响应异常信息，并告警。

                降低复杂度：结构（调用链长度）、算法、环路复杂度

                        结构：系统设计阶段，遵循模块独立性，使用设计原则、设计模式；模块独立性：小团队开发、独立选择技术、独立部署、运行不依赖其他服务；单一职责：机构中心只关系医院相关功能、订单服务只关注用户的订单信息处理；责任链模式：系统调用需要过滤未登录的用户，对每次操作数据都要有日志记录；

                        算法：减少时间复杂度、注意空间复杂度、两者均衡、并行化；1）高频计算：预计算结果缓存，订单统计；2）负载决策：分治法，医院、医生查询根据购买的关键字打标区分开来，分级处理；3）实时数据：采用惰性加载，体检套餐列表图片划到展示；

                        环路复杂度：一个函数中，if数量<10，行数<80；采用提炼函数设置有意义的函数名；

        双机热备：采用了异地多活方式，系统可以分钟级切换，防水火地雷战，平时使用流量分发策略，使两个云的系统都可接受流量提高利用率。

        服务器集群技术：负载均衡，权重（机器硬件分级）。

数据库设计

过程：

         用户需求分析：用户要求。方法自顶向下、自底向上

         概念结构设计：目标：生成E-R图

                 过程：需求分析 – 分ER图设计 – 总体ER模式设计（消除冲突）

         逻辑结构设计：目标：ER图 转 关系模式（属性、关键字）（反规范化）

         物理结构设计：确定数据分布 – 确定数据存储结构 – 确定数据访问方式。（分结访）

         数据库实施阶段：建立实际的数据库结构 – 数据加载 – 数据库试运行与评价。

         数据库运行与维护：性能检测和改善 – 备份和故障恢复 – 数据库重组和重构。