架构设计本质-架构思维

向右看齐 2022-09-11 07:09 252阅读 0赞

前言：  
本篇文章结合多数人在工作中的模块开发，架构设计情况，以及相关权威性文章和书籍，总结下如何在开发过程中，慢慢养成架构思维，共设计以下几个方面：

正文：  
简单介绍下架构设计：  
软件架构是一个系统的草图，描述了组成架构的组件及各个组件之间的关系，组件和环境之间的关系，以及设计组件的原则，组件可以是子系统，模块，类，方法等。

架构设计是架构决策的过程，设计系统分解，接口定义，通信协议定义，交互关系和集成方式确定。  
架构决策是指在架构设计中统筹全局并作出决定，权衡，取舍，比如将系统拆分为几个子系统，子系统的职责是什么，子系统如何进行交互，如何调用和采用什么集成机制，是用什么开发语言和技术框架。

养成架构思维的相关几大原则：  
先看一张汇总图，对本篇文章的说明：

一：分解  
在软件架构中，分解是一种非常重要的手段，是“分而治之”思想的体现，“分而治之”是处理复杂问题的通用方法，能保证分解后的各个部分高内聚、松耦合，最终形成一个整体，多层架构，OSI七层模型等都体现了此思想。

二：集成  
微服务架构倾向于减少中心消息总线的依赖（类似于ESB：企业服务总线），将业务逻辑分布在每个具体的服务终端，在微服务架构中采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。  
注意：集成的难点在于数据服务设计，数据的一致性，分布式查询。

三：动静分离  
动静分离是最重要的架构思维之一，是将静态资源和动静分离，通过不同的系统进行访问的架构设计访问，在设计架构时要注意二者的结合。

四：复用  
SOA参考架构的核心思考模式，包括最近比较火的受关注的业务能力组件化，组件能力服务化，平台+应用，共享中心建设，共性能力下沉，等都是复用的表现，即使设计一个小系统，也需要将各个模块需要用到的共性功能抽取为可复用的共性组件。

好的系统设计具备可扩展性，灵活性，可插入性，一个复用性较好的系统就是一个易维护的的系统。

五：分层  
分层架构的一个重要原则是每层只能与位于其下方的层发生耦合，分层相对重要，架构在设计中要考虑分层，其核心仍然是资源+服务+应用的三大层，这样的分层仍然是SOA参考架构的核心架构。

分层的目的是通过分层理清整个应用的构建过程，并保证了各层之间的独立设计和松耦合。

六：模式  
模式是所有思维模式里面的一个重点，架构模式是一个通用的，可重用的解决方案，架构设计中的模式匹配就是将最终的业务域问题匹配到对应的技术实现上，根据业务需求来挑选最合适的技术，而不是用主流和最先进的技术去反推业务。

架构设计模式一般有分层模式，客户端-服务器模式，代理模式，P2P模式，MVC模式，主从设备模式等常用模式。

七：抽象  
同样的，抽象也是架构设计思维里面的一个重点，其中包括两个层面的内容：

一个是常说的归纳方法，即各种类似场景的实现套多了，自然就归纳成了一种规则或方法出来共以后的设计用。

另一个是抽象，它更加重要，即将非类似场景中的共性内容总结出来，进一步抽象为类似的东西，以更加方便的适应各种变化。

八：结构化  
结构化是一种从框架到细节的思维方式，强调在分析问题的过程汇总中，不先入为主，不马上陷入细节。结构化也被称为表格化的思维结构，强调结构和逻辑，通过结构的完整和逻辑的严密来保证结果的正确。

九：迭代  
迭代思维是我们在架构思考中需要考虑的另一个内容，没有最优的架构，只有不断进化的加油和最合适的架构，因此架构本身也随着业务需求的变化不断迭代和烟花，而不是追求用最新的技术一步到位。

借用一句名言：“凡事预则立不预则废”，在软件初期，投入精力进行架构设计是很有必要的，这个架构就是我们再后续的设计，编码过程中依赖的基础，我们应用迭代方法的最大目的就是稳步的改进软件架构。

十：勿做过多设计  
如果架构师装早的功能无法迎合需求或者实现业务目标又或者是不必要的特征，则会出现过度设计的现象，这一般是因为不清楚项目需求或者不确定架构的性能。

为了避免过度设计的现象，我们需要是需求透明化，不需要做超出需求的设计，不需要假设不存在的极端条件做系统架构设计。  
否则会出现以下问题：  
1.开发时间和成本问题  
2.维护成本问题

还没有评论，来说两句吧...