成都网站seo分析,如何做企业网站加v,现在还有人做网站吗,做网站二维码配图由腾讯混元助手生成 这篇文章介绍了软件架构设计中组件设计思想#xff0c;围绕“组件间聚合的张力”这个有意思的角度#xff0c;介绍了概念#xff0c;并且结合架构设计示例对这个概念进行了进一步阐述。 组件聚合#xff1f;张力#xff1f;这标题#xff0c;有种… 配图由腾讯混元助手生成 这篇文章介绍了软件架构设计中组件设计思想围绕“组件间聚合的张力”这个有意思的角度介绍了概念并且结合架构设计示例对这个概念进行了进一步阐述。 组件聚合张力这标题有种字都认识但连在一起就看不懂的感觉。但别着急往下看就知道了。 虽然类似的思想我们可能也都看过或者已经在使用了但我觉得这个描述很有意思还是花点时间再记录下。 什么是软件组件 组件是软件的部署单元是整个软件系统在部署过程中可以独立完成部署的最小实体。 组件聚合或者拆分的基本原则 芒格给自己的投资活动列了一些基本原则每次投资活动时都会搬出来作为一个检查清单来审视投资活动。 组件设计上以及之前软件模块设计上这些设计原则也是类似作用。当我们做架构设计时可以把这些原则搬出来对比看看。 三个与构建组件相关的基本原则 1.REP复用/发布等同原则 软件复用的最小粒度应等同于其发布的最小粒度。不遵守的话组件可能很难被复用。 2.CCP共同闭包原则 将由于相同原因而修改并且需要同时修改的东西放在一起。将由于不同原因而修改并且不同时修改的东西分开。不遵守的话即使简单的变更可能都会影响到许多组件。 3.CRP共同复用原则 不要强迫一个组件的用户依赖他们不需要的东西。不遵守的话可能会引起很多不必要的发布。 什么叫组件聚合的张力 上述三个原则之间彼此存在着竞争关系。REP和CCP原则是黏合性原则它们会让组件变得更大而CRP原则是排除性原则它会尽量让组件变小。软件架构师的任务就是要在这三个原则中间进行取舍。 这是一张组件聚合三大原则的张力图图的边线所描述的是忽视对应原则的后果。 只关注REP和CRP的软件架构师会发现即使是简单的变更也会同时影响到许多组件。相反如果软件架构师过于关注CCP和REP则会导致很多不必要的发布。 优秀的软件架构师应该能在上述三角张力区域中定位一个最适合目前研发团队状态的位置同时也会根据时间不停调整。 例如在项目早期CCP原则会比REP原则更重要因为在这一阶段研发速度比复用性更重要。一般来说一个软件项目的重心会从该三角区域的右侧开始先期主要牺牲的是复用性。然后随着项目逐渐成熟其他项目会逐渐开始对其产生依赖项目重心就会逐渐向该三角区域的左侧滑动。 换句话说一个项目在组件结构设计上的重心是根据该项目的开发时间和成熟度不断变动的我们对组件结构的安排主要与项目开发的进度和它被使用的方式有关与项目本身功能的关系其实很小。 说两个事例 单体服务与微服务 后端服务架构上的单体服务和微服务就是类似的。早期功能还不那么复杂这时候搞个单体服务就够用随着业务规模扩大和需求增加这时候单体服务的缺点也暴露出来可能一点微小的变更都需要进行全局发布这时候就拆分成了多个微服务。 最近刚好看到一篇腾讯文档的文章《回归单体成为潮流腾讯文档如何实现灵活架构切换》。 腾讯文档在 C 端场景中以微服务的形式部署在 TKEx 平台上而在私有化场景将微服务合并成少数几个单体服务。 腾讯文档的这个自动化操作还是挺有意思。不过本质上它的组件还是拆开的只是在部署形态上合在一起了。 控制面与转发面分离 我自己最近一个项目中也有类似的示例。初期设计的是网关-控制器的架构这里的网关既承担了控制面的功能又负责转发面的事情在初期没什么问题。可随着业务需求的发展控制面和转发面都加了越来越多的功能这时候团队考虑转控分离控制面独立出一个agent来交付网关单纯负责转发面事务。这样的好处也显而易见避免频繁的变更也起到了爆炸隔离的效果。 小结 回过头来看大家其实或多或少都接触过这些思想。只是bob大叔用了张力这个表述足够骚气。领教了。 IoT小能手twowinter的其他精彩文章 * 动手创造 13块钱DIY微信小程序远程浇花神器 自制一个 LoRa PM2.5 监测器 语音控制智能家居的抽风小仓鼠 * 技术分享 LoRaEdge LR1120 卫星直连通信解读 深度报道 第1个从太空发回的LoRa信号(含视频) 无线节点的空中唤醒技术解析 * 多元学习 文档啊最重要的还是层次感 你没中过勒索病毒不知道备份有多重要
