栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 软件开发 > 后端开发 > 架构设计

聚沙成塔的架构思想

架构设计 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

聚沙成塔的架构思想

一 点睛

作为架构师,要具备这种思考方式——设计的架构尽量简洁,功能单一,降低复杂程度,尽力复用;在系统之间做到低耦合,把复杂的部分封装到系统内部;把整体使用最多的部分抽象独立,通过组合多个小而简洁的模块,汇聚成一幅完整的架构图。

二 小而简洁

好的架构都是简单的、易于理解的。我们在设计系统的时候,也要追求简洁,控制好系统规模。不要将系统设计得过大,导致系统复杂,不易维护和修改。

一般互联网系统的功能都很繁杂。在设计系统的时候,要把一个大系统分解成互相正交的一些小系统。通过网络通信,指定协议来实现不同模块间的通信。在软件层面做到高内聚、低耦合,以后扩展系统的时候,不用修改所有的地方,只要修改涉及的模块就可以了,减轻测试的负担。

将一个大系统分为多个小系统的优点如下。

1 小系统更灵活且可以复用

如果一个大系统是由多个小系统组成的,那么针对不同小系统的组装,能够实现新的功能。

模块的功能要设计得小些,当其他模块使用某些模块已有的功能时,只要简单组合,就能实现新的功能,不用开发重复的功能。

如果不把一个大模块划分为小功能模块,每个场景做一个功能,那么三个场景会有很多重复的逻辑。当底层数据库或数据存储发生变化时,上层逻辑也要修改。但修改的这些代码和业务逻辑关系不大,也凭空增加了风险。

所以,将一个大系统分为多个小系统,方便组合和复用模块,降低系统复杂度,便于维护,容易扩展。

2 系统升级重构的风险更小

如果把一个大系统划分为多个小系统,那么当对某个模块进行重构的时候,影响的代码是有限的。修改包含 100 行代码的文件的风险,要小于修改包含 10000 行代码的文件的风险。

针对小系统的替换,也让系统部署风险更小,如果发布后有问题,那么需要回滚的功能只占全部功能的一小部分,不用全部回滚,影响也更小。

3 开发周期变短

如果软件功能不可分解,即使增加开发人员,也不能让开发周期变短。把系统分解为多个正交的模块,指定好互相调用的协议,就可以把系统交给多组开发人员进行开发,成倍地缩短开发周期。

由于开发团队的规模变大,每个团队更聚焦于其所负责的模块,对开发的模块质量也有正向帮助。

一个程序员一次交付一个大模块,和分十次交付十个分解的小模块,总投入的精力是差不多的,但单位模块交付的期限缩短,相关依赖可以并行,软件质量的差别也会很大。

模块间的开发相互独立,不至于一个模块出了问题,影响整个系统。如果哪个模块比较重要,则可以增加资源来保障模块的可用性,把有限的资源用到最需要的地方。

4 每个系统的功能更专注、更内聚

每个系统的功能更专注、更内聚时,能够充分提升系统的性能和准确性,也能够合理利用资源。

把一个大系统划分为更多小而简洁的系统是系统最终要追求的目标。

系统划分的规模要根据团队规模和系统功能来定。

如果几十个工程师负责一个系统的开发工作,那么肯定要细分系统,这样才能做好分工和合理组装新功能。如果是早期创业团队,或者制作产品最初的原型,那么还是越快实现产品越好。

如果预见未来业务会越做越大,那么可以按照划分原则,预埋以后划分的功能。

另外也要预防过度设计。

即使团队规模和业务规模达到能够划分的程度,也要注意划分的粒度。分得越细,会造成调用关系增多,一些公用的部分本来只需要一次调用,实际却被分为多个接口组合调用才能实现功能,而且细分的接口还没有单独提供服务的机会。

如何评判划分的粒度是否合理,是否过大或过小呢?

a 当前系统的功能是否太多,开发人员不能掌握全部的系统信息,每次都需要专门查询才能了解系统的功能?

如果答案是肯定的,那么你已经感觉到系统规模太大,这时就需要检查系统,将系统划分得更细,改变这种现状。

b 如果系统包含多个业务模块,那么是否有些功能是重复的,而且这些重复的功能都要通过多个不能复用的子模块组成起来实现功能的调用?

如果答案是肯定的,那么说明系统划分得有些过细了。这时要检查重复且多步调用的地方是否需要合并,或者增加一个代理层,对外屏蔽内部的多个调用细节。

三 扩展能力

积少成多,集腋成裘。之所以架构要采用从小到大的集成方式,是因为资源有限,短时间内直接制造出最终态不可行。所以要先设计出一些小的,满足当前可用的模块或组件。以后系统需要变大时,可以复用从前的模块或组件,构造更多功能的系统。

扩展性的分类有:协议扩展性、函数扩展性和部署扩展性。

1 协议扩展性

通信协议是不同系统沟通的基础,设计一种具有扩展性的协议,可以在两系统接口的协议不变的情况下,实现互不干扰地升级,保证团队间沟通的成本最低,每个系统实现高内聚、低耦合。

要实现协议可扩展,被调用方就需要让调用方提供必需的参数,不要让调用方为了实现功能而了解很多系统内部调用细节。这样对外能够更好地封装功能接口,暴露最少的信息,方便以后扩展服务端的功能。

另外,尽量给调用方提供通用的协议,使用通用的协议功能实现个例的需求。

2 函数扩展性

函数与协议类似,可以把协议理解为一种远程的函数。在函数实现的时候,也要考虑同名函数会有不同的版本。特别是在做一些基础组件或 SDK 的时候,对函数参数的设计尤为重要。在一些高级语言中,可以通过设计模块来实现同名函数支持不同的参数类型。

3 部署扩展性

在实现协议扩展性后,还要找到真正的服务器来调用协议。那么被调用方通过什么方式让业务路由到新协议呢?

可以通过服务发现提供、域名或虚拟 IP 地址在业务扩展或更换实体机器的时候让调用方无感知。

转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/911555.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号