架构设计之思考路线

概述

        看过不少本架构设计方面的书籍，如《亿级流量网站架构核心技术》《超大流量分布式系统架构解决方案》《企业IT架构转型之道》《从程序员到架构师》等，看完之后最终发现架构设计思维大同小异，无非都是围绕实现三高（高并发、高可用、高性能）系统来展开，不同书籍侧重面不同。很喜欢马云说过的一句话：书不能都太多，读太多了做的就少了。看了五六本相关书籍之后感觉是时候进行一些总结归纳了，再看意义也就不大了。我们通过书籍看到的知识只有沉淀成自身的知识才算是吸收了，反思沉淀之后我们需要把理解的知识进行输出才算完全消化掉，输出既是对自身吸收情况的检测也是传播知识的一种好习惯。

一、常见的架构模式以及选择分析

        之前汇总过一遍文章【二】架构演进之路-CSDN博客，里面总结了架构演进之路，当时归类的不够完善，实际上架构演进经过了如下历程：

        单体架构-》分布式架构-》SOA架构-》微服务架构-》后微服务时代-》无服务时代

        其中后微服务时代我理解是容器云架构，另一个接触比较少的模式无服务时代，即无服务架构，也被称为函数即服务（Function as a Service，FaaS），是一种云计算模型，用于构建和部署应用程序，无需关心底层服务器的管理。说是无服务架构个人理解也比较少，感兴趣的同学可以去找一些资料进行理解。

        这么多架构模式我们该如何去选择呢，根据个人经历目前要考虑架构模式从这几个中选择就可以了单体架构、微服务架构、后微服务时代、无服务时代。根据业务需求、系统使用场景以及团队人数来考虑我们可以确定采用单体架构还是微服务架构，我们做的新能源行业的数字化业务平台，个人是这么理解的，首先如果系统用在电网侧和发电侧我们尽量使用单体架构，前提是业务量不大的情况下，因为这些场景通常需要出差到电网现场部署和运维，复杂架构存在很大的弊端，其次都是业务量不大的系统，另外就是公司的一些OA类系统优先考虑单体架构，其次就是电网系统通常并发数不高但是数据规模大这样我们就扩展数据层架构就可以了，单体架构的优势就是人员成本低，综合来说就是在满足业务系统需求的前提下尽量选用节省预算的解决方案来做项目。另一方面是考虑使用微服务架构的逻辑，业务体量大的系统我们就需要优先考虑微服务架构了，同时要考虑大家团队规模来进行微服务规划。

二、架构设计过程中思考路线

        本章节主要讲一下个人在做系统架构设计过程中的思路路线，如下图概括了个人的思考路线：

        很多时候我更愿意把系统软件的日常工作统称为软件设计，软件设计包括了：需求分析、抽象建模、系统设计、数据设计、非功能设计。接下来分别介绍一下各流程节点所做的工作以及产出成果。

需求分析

        这阶段主要是产品经理要投入的工作，产品经理和需求方频繁互动之后需要产出需求文档、原型设计，这些产出是非常重要的，直接影响到系统的顺利交付工作，等产出这些资料之后，产品经理需要组织软件研发工程师，UI设计师，测试工程师一起开需求评审会议确定需求设计稿，定稿之后软件研发工程师，UI设计师，测试工程师就可以启动了，UI设计师在需求定稿之后给出UI设计图，测试工程师着手用例的规划和编写，此时研发工程师开始着手抽象建模工作了。

        这一部分产出的资料：需求文档、原型设计、UI设计图

抽象建模

        这一步由软件研发工程师主导推进，工程师们根据产品需求文档和原型设计进行领域建模，在建模过程中需要和产品经理频繁互动避免需求理解偏差。

系统设计

        这一步是很核心的工作，系统交付质量的好坏就看设计的好坏了。系统设计个人理解又可以分为：技术方案选型、代码结构设计。其中技术方案选型包含了架构设计的工作，架构设计我们可以采用如下的方法进行设计：

而三高系统架构设计期间我们要考虑如下方面的技术：

        代码结构设计个人是这么理解的，一直以来我们都是采用MVC模式来进行，从2019年领域驱动设计概念问世，我们就多了一种选择了，这两中设计思路代码结构不一样，其中包结构以及类的规划也存在差异，还有就是代码结构设计期间我们需要确定代码规范，从而使得系统整体设计一致。

        这一部分要产出的资料是非常之多的：技术文档、接口文档、系统部署手册（网络拓扑图）、系统测试用例及手册、属性值数据字典说明文档、源代码、源代码说明手册、系统概要设计说明书（架构图）、系统技术说明书、使用手册、维护说明书

数据设计

        这一部分的设计可以说是重中之重了，大学课程中经常看到：数据结构+算法=程序，个人得出一个广义上结论：数据库+程序=系统。数据层没设计好首先影响系统稳定性，另外后期扩展和迁移也都是比较困难的，所以再做数据设计过程中我们要考虑周到。数据层技术选型如下：

        选好数据层技术之后，还需要确定好架构方案，因为数据层技术一般提供了如下的架构方案可供选择：

        这一部分产出的资料：数据库设计说明书、数据库脚本及相关服务器脚本

非功能设计

        非功能设计在整个软件设计中是单独要考虑的，不同的系统有不同的非功能需求，非功能设计我们需要考虑如下方面：

        这些也都是个人在做过不少大大小小的项目之后总结归纳出来的，具体的指标会根据系统需求调整，但是这些方面我们在设计中要思考到。

总结

        本文算是对个人现阶段在软件设计方面的沉淀输出了，后面写的有点匆忙，后面有耐心继续再完善。再写本文之前个人也是阅读了5-6本以上的行业大佬编写的系统架构设计书籍，然后结合自身的项目经验理解分析得出了自己能接受的思考路线，各书籍编写有好有坏，但是软件设计路线大同小异，读者需要结合自己的经验吸收总结才好，尽信书不如无书。

        个人现阶段的观点希望读者看到也是有选择的进行吸收采纳，欢迎在评论区留言交流！