架构设计实践

Posted 2022-11-30 tterminator

一、架构设计原则

架构原则源于业务目标。

架构设计不像数据公式或者定律，很难一概而就。很多时候是设计者（架构师）的各种设想，各种权衡折中而符合系统需求的智慧输出。一些好的架构设计原则可以确保设计决策在一定程度上能够满足需求。

1、形成架构原则的过程

架构原则不是某个架构师拍脑袋决定，可能是架构师提出最初文档，然后经过了团队成员内部反复讨论和共同认可后才得以确定和精炼的。形成架构原则的过程：

架构原则要SMART

具体SMART原则有不同的解释：
SMART原则1（S=Specific具体、M=Measurable度量、A=Attainable实现、R=Relevant相关、T=Time-bound时限）
SMART原则2（S=Specific具体、M=Measurable度量、A=Attainable实现、R=Realistic实际、T=Testable 可验证）

2、架构原则分级

下面部分图来自《京东架构介绍》ppt。

1)、系统级架构原则

2)、业务架构原则

3)、应用架构原则

4)、数据架构原则

5)、代码架构原则

具体参考《设计模式原则详解》和《设计模式概论》提到相关原则。

6)、技术架构原则

3、15条普适架构原则

我们掌握前人总结的经验，让我们站在巨人的肩膀上高山远瞩。《架构真经》这本书简单阐述了架构设计的一些常用的原则。罗列一些常用的原则，下面是15个具有普适价值架构原则 ：

1、N+1设计 ：开发的系统在发生故障时，至少有一个冗余的实例
2、回滚设计 ：确保系统可以向后兼容。
3、禁用设计：可以关闭任何发布功能
4、监控设计 :在设计阶段就要考虑监控，而不是在部署完成后。
5、多活数据中心设计
6、采用成熟的技术
7、故障隔离 ：
8、水平扩展
9、非核心则购买
10、使用商品化硬件
11、快速迭代
12、异步设计
13、无状态设计
14、前瞻性设计
15、自动化

二、架构模式

什么是架构模式？在维基百科：架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式，但范围更广。

架构的本质是管理复杂性。如果你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。

O’Reilly 出版过一本免费的小册子《Software Architecture Patterns》， 介绍了五种最常见的软件架构，是非常好的入门读物：

1. 分层架构（比较传统的单体架构）
   常见的四层结构：
   

2. 微服务架构（服务分割：当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代）
   微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景）
   

4. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦）
   

5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构）
   随着Docker、Kubernetes等容器化技术的快速发展，上述关于云架构描述有点陈旧了。当前最新的云原生架构，以Docker+Kubernetes为核心，尤其是容器编排Kubernetes 已经成为事实上的行业标准。

三、架构设计

架构设计非常适合使用瀑布模式开发，特别是需要升级架构的系统。

而TOGAF9的ADM(架构开发方法) ，以需求为中心形成循环的方式表示，即一个阶段的架构工作完成后的成果直接输入到架构工作的后续阶段中去。但总结起来就是：

四、架构需求分析

1、架构设计的需求分析从哪来

需求分析的前期工作是愿景描述及愿景分析, 即愿景分析就是需求的前期调研.

从软件过程来看，需求分析是一个承上启下的阶段–“上承”愿景，“下接”设计。需求分析的工作内容包含如下三方面：

需求捕获: 理解沟通
需求分析:做什么,有哪些问题
系统分析:原因是什么, 怎么做

三者不是独立无关的阶段，而是相互伴随、交叉进行的。

需求捕获: 从各个方面收集需求, 并理解需求.典型的需求捕获是使用“需求采集卡”：需求描述、需求提出者、需求记录者、需求类型等。
需求分析:需求捕获得到的是“原始需求”，而需求分析则对各方面收集到的需求进行分析、整理、归纳、论证形成明确的需求。比如, 产品经理说,现在系统不稳定, 需要重构架构保证系统稳定. 这只是一个愿景, 我们需要把这个需求形成一个明确的需求: 可行性99.99%, 要完成这个指标,需要做哪些工作.

2、需求分类:需求结构化

收集需求是多而杂, 我们需要理解并整理, 通过二维需求观，将“需求=列表”的传统观念，一下子拓宽了维度。有了视野和思维上的提升。

二维需求观:

首先，需求是分层次的:
1、有组织级的需求
2、用户级的需求
3、开发级的需求。

其次，需求还必须从不同方面考虑。 需求可分类为三类：
1）功能需求：更多体现各级直接目标要求,系统具体要做什么. 有哪些功能点.
2）质量需求：运行期质量 + 设计质量+用户质量+系统质量.
3）约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素.

ADMEMS矩阵，可作为需求梳理和需求评审的工具:

参考《软件架构设计：程序员向架构师转型必备(第二版)》

五、高可用架构

所谓业务可用性(availability)也即系统正常运行时间的百分比，架构组最主要的 KPI (Key Performance Indicators ，关键业绩指标)。对于我们提供的服务（web，api）来说，现在业界更倾向用 N 个9 来量化可用性， 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。

我们先列出目前我们系统有哪些环节,每个环节是否薄弱. 客户端访问服务器端，经过很多环节，任何环节出问题，都不能访问：

接入层：

1、dns被劫持：域名是否使用https。
2、黑客攻击：是否有弱密，服务器权限，数据库权限
3、ddos攻击：是否有必要使用高防IP接入流量。
4、CC攻击：免费和收费版域名分开，网关是否有限流和防刷措施。

应用层：

1、应用服务器宕机。
2、应用服务bug。
3、第三方服务不可用。

服务层：

1、服务不可用或者出现bug
2、第三方服务不可用。

数据层：

1、数据库服务器磁盘损坏导致数据库不可用等

高可用方案

参考《《大型网站技术架构+核心原理与案例分析》》

六、分布式服务治理

服务治理定义

服务治理的简单定义：管理分布式的多服务，包含服务从设计、开放、运行的整个生命周期，其内容包括架构原则、研发流程、治理规范等。

为什么需要服务治理

第一、业务需求

从简单的单体应用开始，随着业务的增长，单体应用随之拆分，系统演变成分布式多服务、微服务。随着业务规模扩大服务也随之增多，我们需要管理、治理线上运行的各个服务，保障服务的SLA，从而提高系统的运行效率，稳定性。因此服务治理主要针对于当前分布式架构下多服务、微服务等。

第二、技术需求

分布式系统是由多个服务组装完成，这里面就需要服务如何集成到系统，如何修改配置，权重等内容。这就需要一个服务治理框架完成自动服务注册发现，需要治理平台管理服务配置，权重调整，监控检测相关内容，以提高服务治理效率。

七、分布式链路跟踪

在分布式系统架构里面，往往包含众多应用服务，这些服务之间通过RPC调用来完成业务请求，如果其中某个RPC请求异常、超时和错误，很难去定位。这时我们需要分布式链路跟踪，去跟进请求链路到底有哪些服务，请求参数、请求结果、超时异常等情况，就可以清晰可见，然后监控服务运行状况和快速定位问题。

在这种情况下，一般都会引入APM（Application Performance Management & Monitoring应用性能监控管理）系统，通过各种探针采集数据，收集关键指标，同时搭配数据呈现和监控告警，能够解决上述的大部分问题。

Google开源的 Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》（即《 Dapper，大规模分布式系统的跟踪系统》），这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。

Dapper的基本思路：是在服务调用的请求和响应中加入SpanID，标明上下游请求的关系。利用这些跟踪信息，可以可视化地分析服务调用链路和服务间的依赖关系。

在谷歌论文《 Dapper，大规模分布式系统的跟踪系统》的指导下，许多优秀开源的APM系统应运而生。

目前市面上开源的APM系统主要有CAT、Zipkin、Pinpoint、SkyWalking，大都是参考Google的Dapper实现。

1、各个开源APM简介
CAT： 是由国内美团点评开源的，基于Java语言开发，目前提供Java、C/C++、Node.js、Python、Go等语言的客户端，监控数据会全量统计，国内很多公司在用，例如美团点评、携程、拼多多等。从网上相关资源查阅：集成方案是通过代码埋点的方式来实现监控，比如： 拦截器，注解，过滤器等。 对代码的侵入性很大，集成成本较高。风险较大。

Zipkin： 由Twitter公司开发并开源，Java语言实现。如果是基于spring cloud 微服务系统，结合spring-cloud-sleuth使用较为简单， 集成很方便。

Pinpoint： 一个韩国团队开源的产品，运用了字节码增强技术，只需要在启动时添加启动参数即可，对代码无侵入，目前支持Java和php语言，底层采用HBase来存储数据，探针收集的数据粒度非常细，但性能损耗大，因其出现的时间较长，完成度也很高，应用的公司较多

SkyWalking： 国人开源的产品，主要开发人员来自于华为，2019年4月17日Apache董事会批准SkyWalking成为顶级项目，支持Java、.Net、NodeJs等探针，数据存储支持mysql、Elasticsearch等，跟Pinpoint一样采用字节码注入的方式实现代码的无侵入，探针采集数据粒度粗，但性能表现优秀，且对云原生支持，目前增长势头强劲，社区活跃，中文文档没有语言障碍。

八、参考

https://blog.csdn.net/hguisu/article/details/78258430