系统架构设计师论文参考

本文首发微信公众号——全副武装的大师兄

2024年下半年系统架构设计师考试在即，由一年一考转为一年两考，考试频次增加了一倍，不敢说考试难易程度是否发生变化，但每年实实在在的多了一次机会给有需要的人。

本次分享的是备考期间准备的4个方向的论文，其中云原生架构这篇论文前面已经发过（对每一段怎么写做了说明）。
一般来说，架构论文预备一个项目，分大方向准备论文即可。
为什么这么说呢？首先，离考试时间太远的项目不适合。我们都知道技术迭代较快，如果2024年了，你拿2012年的项目来写，说明没有与时俱进，或者说明你很久没有做项目了；其次，太小的项目不适合。项目资金规模只有十几万，说明项目本身不大，可能就是个单机系统，达不到架构的高度；最后，太近的项目不适合。比如11月6号考试，你设计的系统在8月上线试运行，刚过完试运行阶段或还在试运行阶段，还不能充分说明你设计的系统是否达到预期目标。这样排除下来，能选择的项目就不多了。
但是别死心眼，项目虽然只能写近两年的，但是许多技术是通用的呀！可以把用到的技术往一个项目上怼。
这样的话，一个项目，写所有方向，一个方向写许多主题。

比如，你准备了数据脱敏的项目，那么这个项目你可以写系统建模、软件架构设计、系统设计、分布式系统设计、可靠性分析与设计、系统安全、新技术等。刚好，你又准备了一篇微服务架构的论文，考了云原生、系统架构、软件架构风格、面向服务的架构、无服务架构、容器技术、DevOps、事件驱动架构、Mesh架构中的一种，那么提前恭喜你，这次考试，论文将不再是你的绊脚石。
分大方向准备论文，剩下的时间多去了解一些技术，归纳这些知识之间的异同，并思考如果论文考这个点，哪篇论文能利旧，需要补充哪些点，修改哪些地方，按这个方式准备论文就能够做到无招胜有招了。
除此之外，论文正文的第一、二段，和倒数第一、二段属于万金油段落，每篇论文都可原封不动的使用这些万金油段落，这里占到的字数将近1000字！（详见下面论文）
按照这种方法准备架构论文，你甚至不需要架构经验！
当然，如果你项目经验丰富，但是论文没过，可能只是写作方面需要注重技巧。

目录
1.系统可靠性设计

2.基于架构的软件设计方法

3.Web系统性能优化技术

4.云原生架构

系统可靠性设计
摘要
2018年3月，我单位联合某省省厅研发了《数据脱敏系统》项目，解决了数据在其生命周期的存储、传输、使用和共享环节中的安全问题。该系统以数据脱敏功能为核心，分为资源模块、敏感属性模块、脱敏规则模块、脱敏管理模块、权限模块、审计模块等。在项目中，我担任系统架构设计师职务，主要负责系统架构相关工作。

本文以该系统的脱敏功能、数据库功能、敏感数据检测功能为例，论述了软件容错技术在具体项目中的运用。通过采取集群化的形式进行应用部署，通过主从形式的数据库部署，通过程序设计方面进行软件的容错与检错。以上措施对提高系统的安全性、可用性、可扩展性方面起到了很好的效果，保证了系统的稳定运行，获得了用户一致好评。

正文
笔者在一个专为政企建设信息系统的集成商任职，过往成果有《某省厅网技综合平台》等。2021年3月，我单位联合某省厅研发了《数据脱敏管理系统》项目（以下简称“系统”），解决了数据在其生命周期的传输、存储、使用、共享环节的安全问题，保护了数据安全性和可用性。

该系统以脱敏功能为核心，分为资源模块、敏感属性模块、脱敏规则模块、脱敏管理模块、权限模块、审计模块等。资源模块主要负责数据的输入输出管理，能够将数据接入和导出至不同数据源（如mysql, neo4j, hive, 文件等），并负责将抽取的数据发送到敏感属性模块；敏感属性模块负责对数据中的敏感字段自动发现，并能够一键核实敏感字段，支持用户选定敏感字段；脱敏规则模块根据用户核实的敏感字段，灵活组合不同脱敏规则，并支持用户上传或直接在页面编写脱敏规则；脱敏管理模块负责对数据实施动态或静态脱敏，还能够对数据实施可逆和不可逆脱敏；权限模块用于系统安全管理员对不同部门的不同角色赋予不同的权限，实行对系统用户的权限管理；审计模块用于系统审计管理员对系统操作的监督和核查。在项目中，我担任系统架构设计师，主要负责系统架构设计相关工作。

系统需要支撑省厅所辖公务员对数据的脱敏，为了保证系统在数据脱敏、可逆脱敏期间的稳定运行，对系统的容错性要求非常高。传统的单块架构设计早已无法满足用户日益增长的需求，存在严重的可靠性和性能问题，且难以扩展。因此该系统的系统架构中必须考虑软件可靠性设计的应用。常见的软件可靠性设计有：1.容错技术。容错技术有恢复块设计，N版本程序设计，冗余设计。冗余设计包括结构冗余、信息冗余、时间冗余、冗余附加等，结构冗余又分为静态冗余、动态冗余和混合冗余；2.检错设计技术。检错设计技术要考虑的几个要素有检测对象，检测延迟，实现方式和处理方式；3.降低复杂度设计。通过简化软件结构，缩短程序代码长度，优化软件数据流向，降低软件复杂度，从而提高软件可靠性。

系统以微服务架构作为基本架构风格，基于spring cloud框架，采用java语言开发，将系统分为前端web服务，平台保障服务，业务服务。在系统开发过程中，综合web软件的性质，采用了较多容错技术，这里以集群技术、数据库主从部署和降低程序复杂度为例，介绍软件容错技术在具体项目的运用和实施后的效果。

1.集群技术。业务服务主要分为数据适配服务、敏感属性探测服务、脱敏算法服务、脱敏服务等，系统中各服务如果采用单机部署的方式，那么当服务器发生故障时，整个平台将不再提供任何服务，所以达到规模的应用需要采用集群的部署方式。以系统中脱敏管理模块的脱敏服务为例，数据脱敏属于耗时操作，用户提交的待脱敏数据需要统一存入消息队列中排队，然后由脱敏服务从消息队列中依次读取进行脱敏和转储。如果脱敏服务只部署在单台服务器上，那么当脱敏服务因对用户提交的大量数据无法及时处理，而导致脱敏服务宕机时，后续所有待脱敏任务都将被阻塞。通过多台服务器同时部署相同应用的脱敏服务集群，并结合euraka业务服务中心的软件负载均衡功能，当系统正常工作时，多个脱敏服务并行运行，能够提高脱敏效率；当服务集群中的部分服务宕机时，控制中心将未完成的脱敏数据发往正常提供服务的脱敏服务，此时，系统仍可正常对外提供脱敏服务，并能够给故障服务留出时间恢复服务。通过集群技术，实现了各个服务可用状态的实时监测、自动转移失败任务，防止了单个服务宕机导致整个系统不可用的问题，保证了业务的连续性，提高了系统的可靠性。

2.数据库主从部署技术。集群中各服务的读写操作都访问单机数据库，当脱敏任务激增时，大量的连接和读写将导致数据库出现不可用的情况，最终导致整个平台无法正常提供脱敏服务。对于数据脱敏系统来说，后端数据库存储的稳定性是极其重要的，所有用户的操作记录，所用脱敏字典策略（周期更新），部分脱敏后的数据（大部分脱敏数据对接到其他系统存储处理）都存储在数据库中。如果运行过程中数据库频繁宕机，带来的问题是不可容忍的。这里要求数据库读写有非常强的稳定性和容错性，考虑到业务读多写少，为了解决数据库的读性能瓶颈，本系统采用主从式部署数据库，实现读写分离架构。业务数据在写数据时，访问主数据库，主数据库通过主从复制机制将数据同步更新到从数据库，当业务服务需要读取数据时，就可以通过从数据库获得数据。当主库发生故障失效时，使用HA实现故障切换，将从库切换成主库，实现高可靠性。数据库所依赖的硬件存储采用raid6的磁盘阵列，能够最多同时允许两块硬盘发生故障，而不丢失数据，降低数据文件丢失的可能性。通过主从数据库设计，提高了系统运行的可靠性。

3.降低复杂度设计。有研究表明，当软件的复杂度超过一定界限时，软件缺陷数会急剧上升，软件的可靠性急剧下降。结合笔者以往的设计经验，系统出现不可靠大部分是由于程序内部结构的设计、程序代码长度过长，方法扇入扇出不合理。因此，通过对程序设计方面进行软件的检错是非常重要的。我们主要采取的是防卫式程序设计，例如平台的脱敏功能，需要根据脱敏或逆向脱敏数据的规模，调用脱敏服务对数据进行脱敏或逆向脱敏。当大量用户同时进入脱敏功能，脱敏服务在被调用的一刻如果出现网络拥塞或者丢包，这是脱敏服务必然会收到抛出的错误信息，如果没有通过恰当的容错处理，那么一定会给用户显示进入脱敏失败的错误。这里我们主要采用try-catch机制加多次重试的容错处理机制，就解决了进入脱敏时因网络原因导致进入脱敏失败的问题。同时，还建议开发人员每个方法的代码长度不要超过80行，按照方法单一职责原则进行开发，这样就防止修改方法时，导致调用该方法的功能发生错误。通过约定一些开发原则，能够降低复杂度设计，提高系统的容错性和可靠性。

通过采用了以上可靠性方法和措施后，脱敏服务功能达到了六余度、数据库达到四余度，敏感属性探测时间控制在2秒内，使整个系统达到了可靠性的要求。系统自2022年3月上线已运行1年有余，在数据生命周期的存储、传输、使用和共享环节投入使用，截至目前已脱敏3万余次以上，脱敏数据量达到103T，获得了单位领导同事和客户的一致好评。然而在使用过程中，系统还是出现了可靠性问题。例如脱敏服务虽然使用了集群部署，但是当用户的脱敏数据规模达到TB级别数据以上时，无法在短时间内完成脱敏，我们对这种情况进行分析后，采用了机器学习预测的方法，当脱敏规模较大时，将数据拆分到不同脱敏服务进行脱敏处理，最后能够在用户能接受的时间内完成脱敏。

实践证明，系统能够成功上线，并稳定运行，与采用了充分的可靠性设计密不可分。经过这次数据脱敏系统的实施，我也发现了自身存在的不足之处，今后还会不断更新知识，积累经验，完善本系统各方面的设计，使系统下次实施中更加好用，更好为用户、为社会服务。

其它三篇论文见微信公众号——全副武装的大师兄