【老猿说架构】系统架构设计原则和步骤

简介: 【老猿说架构】系统架构设计原则和步骤

大家好,我是老猿,今天继续专题【老猿说架构】,文章仅代表作者理解或观点,如有不同理解论述欢迎拍砖交流。好,废话不说,直接进入主题。

今天跟大伙聊下系统架构设计原则和设计的步骤,这些把握到位了才能把系统架构设计好,也让大家更能理解到系统架构不是一步到位设计出来的而是逐渐演进出来的,脱离了当前业务需要的架构设计都是耍流氓等,因此在我看来系统架构设计要把握三个原则和四个步骤,具体详见下面阐述。

1:适合原则

架构师首先是技术管理者,技术方案选型权衡取舍做技术决策是核心的职责,那么系统架构设计首先要考虑的就是要满足当前业务出发同时能支持适应业务发展而扩展开发维护,同时也要结合团队技术积累和实力、项目时间和成本投入等全方位的综合评估取舍,而不是为技术而技术,如在系统设计过程挑战最新的技术和模仿业界领先方案,当然根据业务场景适用的主流技术栈或技术框架选型还是支持的,通常这些技术框架是随着技术发展解决某一业务场景而产生的。

     总之适合优于先进原则,不管黑猫还是白猫能抓老鼠的就是好猫。

2:简单原则

    这个好理解,系统架构设计的目的就是解决软件之熵带来的问题,那么系统架构设计能化复杂为简单是每个架构师追求的目标,在我看来这个是最难的,世界上高级的东西都是简单而最难做到的,系统设计过程对业务的理解和抽象、建模等很关键,这个需要深厚的业务和技术内功,那么大家在架构设计过程争取尽可能往简单设计吧。

3:演进原则

    系统架构设计是个动态过程,项目初期能满足当前的业务需求进行架构设计,然后架构在不断地需求迭代开发过程中保留优秀的设计,修复有缺陷的设计,改正错误的设计,去掉无用的设计,使架构逐渐完善不会随着需求功能规模的膨胀而快速腐化,因此当业务快速发展时,架构要扩展甚至重构但有价值的经验教训、逻辑、设计却可以在新的架构中不断延续。

    总之,演进原则优于一步到位。罗马不是一天建成的。

 掌握了设计原则后就要开始系统架构设计了,老猿的理解和经验是需要经过如下四个步骤进行架构设计。

步骤1:全面准确理解把握业务,识别复杂度

    其实这个步骤之前的专题文章系统架构设计思维已阐述过了,架构设计最核心目的就是为了解决软件系统之熵带来的问题,那么在设计架构时首先就要分析系统的复杂度,那系统的复杂度如何识别呢?那么首先我们必须全面准确理解业务当前和近期(一般1-2年)对系统容量指标的要求,也就是我们熟悉的容量指标:

高并发(高性能)

满足业务的增长

追求良好的用户体验

高可用(经常讲的N个9)

系统的服务稳定性和数据一致性

可扩展性

能够适应未来一定业务发展

规模发展

数据规模和未来数据增长速度带来的影响

业务功能规模不断膨胀的适应和扩展实现,即是降低架构腐化速度。

安全要求

各种应用安全漏洞、数据安全存储、传输和显示脱敏等

    以上系统容量指标的要求越高系统实现的复杂度接越高,那么我们要根据业务当前和近期(一般1-2年)对系统容量指标的要求做出适用的系统架构设计,切忌过度设计,比如一个文章发布系统,初期对系统容量的指标要求基本是适应多种类型文章发布和文章访问的速度,做好文章数据结构变化的数据字典支持及引入CDN、文章数据缓存实现基本就够了。

    后续的专题文章老猿会详细讲解针对每种系统容量指标要求如何设计实现,敬请老铁们关注。

步骤2:设计备选方案

    确定系统开发需要面对的核心复杂度问题后,架构设计方案就有了明确的目标,那么我们可以开始进行架构方案设计了,针对每个复杂度问题进行对应的方案设计,通常建议至少设计2-3种方案,然后下一步骤针对备选方案进行横比全方位评估并做最终的方案决策。

    比如为了满足业务高并发高性能要求需要引入缓存,那么我们首先要做缓存技术框架选型,如对缓存技术rabbitMQ、RocketMQ和Kafka进行横比技术选型,选型完了针对缓存使用策略进行详细设计。

步骤3:方案选型决策

 在完成备选方案设计后,我们就需要根据三个设计原则进行综合横比评估,根绝业务需要我们可能选最简单的也可能选最优秀的或选最熟悉过渡的中间方案,方案的决策需要很多维度立体全方位评估考量,并不是只考虑性能高低、技术是否先进等纯技术方面的东西,而是最核心关键从业务出发满足业务需要、同时公司已有的技术体系和积累、团队人员技术水平或搭建容易度、项目时间要求、和测试、运维等兄弟团队的经验等都是评估方案的维度之一。

    预计后续的专题文章老猿会跟大伙讲解方案决策的实操案例,方便大家更深刻地理解掌握。

步骤4:方案(系统)详细设计

    完成备选方案的设计和评估决策后,整个架构设计的框架基本有了,但整体细节方案还没完成,还需继续努力。接下来我们需要最终确定的方案进行细化,使得方案变成一个可以落地实现的方案。

    那么详细的系统架构设计包含的方面比较多,后续再针对每个方面详细讲解。如架构风格实现模型选择、数据库表设计、数据库架构设计、应用服务设计、缓存使用策略设计、程序代码设计、安全应对设计、工程管理等等


文/老猿,写代码写诗写职场的程序猿大叔,倾力原创简单实用的硬干货,转载此文请联系老猿

相关文章
|
1月前
|
运维 监控 负载均衡
Go语言中微服务架构设计与原则
【2月更文挑战第14天】本文将深入探讨在Go语言环境下,微服务架构的设计原则和实践。我们将讨论如何根据微服务架构的核心概念,如服务拆分、独立部署、容错处理、服务治理等,来构建一个稳定、可扩展、可维护的Go语言微服务系统。
|
2月前
|
Java 调度 开发工具
SpringCloud【微服务架构进化论、微服务的拆分规范和原则、为什么选择Spring Cloud、什么是服务治理 】(一)-全面详解(学习总结---从入门到深化)
SpringCloud【微服务架构进化论、微服务的拆分规范和原则、为什么选择Spring Cloud、什么是服务治理 】(一)-全面详解(学习总结---从入门到深化)
186 0
|
6月前
|
架构师 关系型数据库 程序员
空手撸SOLID架构设计原则,六大原则层层解析,你绝想不到
设计原则概述 通常来说,要想构建—个好的软件系统,应该从写整洁的代码开始做起。毕竟,如果建筑所使用的砖头质量不佳,那么架构所能起到的作用也会很有限。反之亦然,如果建筑的架构设计不佳,那么其所用的砖头质量再好也没有用。这就是SOLID设计原则所要解决的问题。
47 0
|
6月前
|
存储 缓存 监控
架构师进阶,微服务设计与治理的16条常用原则
架构师进阶,微服务设计与治理的16条常用原则
230 0
|
7月前
|
架构师 关系型数据库 程序员
空手撸SOLID架构设计原则,六大原则层层解析,你绝想不到
设计原则概述 通常来说,要想构建—个好的软件系统,应该从写整洁的代码开始做起。毕竟,如果建筑所使用的砖头质量不佳,那么架构所能起到的作用也会很有限。反之亦然,如果建筑的架构设计不佳,那么其所用的砖头质量再好也没有用。这就是SOLID设计原则所要解决的问题。
|
11月前
|
运维 Kubernetes Cloud Native
带你读《云原生架构白皮书2022新版》——云原生架构原则
带你读《云原生架构白皮书2022新版》——云原生架构原则
187 3
|
11月前
|
设计模式 缓存 监控
【软件架构】支持大规模系统的设计模式和原则
【软件架构】支持大规模系统的设计模式和原则
|
11月前
|
SQL 缓存 监控
【API架构】REST API 设计的原则和最佳实践
【API架构】REST API 设计的原则和最佳实践
|
11月前
|
设计模式 Docker 微服务
「第二部:容器和微服务架构」(1) 基于容器应用架构设计原则
「第二部:容器和微服务架构」(1) 基于容器应用架构设计原则
|
11月前
|
存储 缓存 负载均衡
「web应用架构」有原则的GraphQL
「web应用架构」有原则的GraphQL