微网站怎么开通,济宁vi设计公司,网站建设能干什么,电商是怎么运营的简介#xff1a; 在日常的开发和设计过程中#xff0c;大家对技术设计上的一些问题往往会面临很多的选择#xff0c;不同的人会有不同的选择。本文介绍的就是我在工作中遇到的一些问题而总结和使用到的一些常用原则。 不管我一生中取得了多大的成功#xff0c;其主要原因都…简介 在日常的开发和设计过程中大家对技术设计上的一些问题往往会面临很多的选择不同的人会有不同的选择。本文介绍的就是我在工作中遇到的一些问题而总结和使用到的一些常用原则。 不管我一生中取得了多大的成功其主要原因都不是我知道多少事情而是我知道在无知的情况下自己应该怎么做。我一生中学到的最重要的东西是一种以原则为基础的生活方式是它帮助我发现真相是什么并据此如何行动。 ——瑞·达利欧Ray Dalio 在日常的开发和设计过程中大家对技术设计上的一些问题往往会面临很多的选择不同的人会有不同的选择每每如此我都会尝试着问自己我做出选择和判断背后的原则是什么
经过这么多年的发展在软件设计过程目前沉淀下来的原则有很多但很多情况下很多原则为了普适性总结得会比较抽象一旦太过抽象对原则的解释和理解就会因人而异譬如高内聚低耦合原则大家都懂但是如何落地和执行却是很难说完全达成一致。因此需要针对一些实际的场景中的问题去总结和补充在大的原则下具化形成大家容易理解一致的相对明确原则。
本文介绍的就是我在工作中遇到的一些问题而总结和使用到的一些常用原则。
一 常用原则总结
1 分层设计相关原则
单向依赖原则
原则上只允许较高层次依赖较低层次不允许反向依赖。我们部门是为B类企业提供金融解决方案的技术部门针对我们部门在金融平台层系统不能反向依赖业务产品层系统。同一层的金融平台层系统之间的依赖不进行限制但会尽量减少同层依赖。
另外我们在解决底层依赖的高层中沉淀了几种基本方式
系统依赖转换为数据依赖接口依赖通过底层定义SPI业务层实现这种做法其实是不得已为之同时我们在设计过程中还是尽可能避免走这条路通过事件机制解耦依赖。
无循环依赖原则
系统设计时尽量减少系统之间的依赖同时需要避免系统之间出现循环调用。这是微服务场景下最容易出现的一个问题尤其是同层的领域系统之间的调用导致系统容易出现循环调用循环依赖带来的一个严重的问题是影响系统的发布和部署问题。
避免跨层调用原则
较高层次不允许之间跨层调用底层。软件设计中进行分层的一个重要目的是通过分层屏蔽底层的实现细节如果出现跨层相当于把底层的实现直接暴露了。譬如门面服务层绕过领域服务层直接调用DAO层进行数据读写操作一旦需要重构修改原有的DAO层接口就发现升级改造成本巨大我不知道有多少个团队也面临过这种痛苦。
单一职责原则
该原则由罗伯特·C·马丁Robert C. Martin于《敏捷软件开发原则、模式和实践》一书中提出的。这里的职责是指类变化的原因单一职责原则规定一个类应该有且仅有一个引起它变化的原因否则类应该被拆分There should never be more than one reason for a class to change。
这个原则虽然提出时是解决类的职责定义问题但实际上在对模块的划分上也有指导意义。该原则虽然很简单但是往往也容易被忽视。
在最近的项目中我充分体会到这个原则的作用我们部门的金融网络系统主要解决机构标准化对接问题我们将系统分为了上下两层下层通过标准化的接口对接机构提升机构跨产品的复用能力上层是产品扩展层通过提供标准接口给到上游的业务产品层支持同一个产品接入多家机构屏蔽机构差异。我们判断一个功能到底属于机构对接层还是产品扩展层的一个简单的原则是如果新增一家机构能否做到只影响机构对接层而保持产品扩展层代码不改反过来如果新增一个产品是否能做到只修改产品扩展层机构层能否不改代码。同时为了避免这个原则被突破我们甚至在机构对接层的代码中去除了所有和产品有关的参数这样根据产品定制的逻辑天然无法放到这一层。
数据冗余
架构设计应该使得系统中数据的冗余最小。譬如我们在实践过程中接口设计时在Javadoc上强制指定接口的必传参数尽量做到最小集减少上游系统使用接口的成本。另外要求在接口实现时提前进行参数校验不让不满足要求的数据冗余到系统中。
为了提高系统性能备份节点和子系统/模块必要时需要对数据进行缓存当发生变化时必须有相应的机制保证缓存数据的一致性和有效性。
2 质量属性相关原则
数据安全
这块在我们金融业务部门中尤其突出金融由于其特殊性往往需要收集大量的客户真实和隐私数据数据安全是设计中需要重点考虑的问题通常我们会主要关注以下三个方面的问题
数据存储安全敏感数据加密、日志输出脱敏。数据传输安全包括加密、传输通道规范最少字段传输够用原则尤其是我们金融部门需要将数据输出给到外部第三方机构情况比较多这块上面会控制比较严格。数据输出展示前端展示需要防止水平越权另外前端的展示可以埋点和方便数据采集。
3 资损防控
可核对和可监控上下游系统的数据模型核对关联关系简单、稳定具备通用性和产品无关。可熔断对关键资损链路需要做到可熔断。
对金融技术部门而言资损防控是第一位而我们在实际过程中发现由于前期的一些系统在设计之初没有考虑资损的防控导致核对或者监控的成本很高因此在后来的系统数据模型设计时重点会去review是否具备可核对。
4 并发控制
悲观锁代码编码规范——一锁二查三更新。乐观锁必须在事务内更新。
5 热点问题
避免流量倾斜导致单台机器/单个数据表/数据库集中读写。这个需要在设计时充分提前预判业务的发展规模和系统的容量问题。在实际实施过程中我们会提前按照3~5年左右的业务规模来设计。
6 数据倾斜
分表分库规则在设计时需要考虑数据分布均匀避免单库或者单表数据倾斜。数据倾斜这个在之前踩过比较大的坑在系统设计之初没有结合业务场景去考虑系统的数据存储层设计导致数据出现严重倾斜数据库操作出现瓶颈现在是我们在设计存储层方案时必须要考虑的一个原则。
7 性能原则
可压测对性能要求高的链路需要做到可以压测。这个主要是由于每到大促就需要重新梳理和改造压测链路耗时费力苦不堪言。
8 事务控制相关原则
优先使用编程式事务为了更好的控制事务一般要求使用编程式事务避免潜在的跨事务问题。事务更新需要保证顺序一致性强一致要求还是最终一致强一致是否会涉及到跨库事务操作时需要相同记录的更新顺序保证一致。事务中不进行远程调用。
9 一致性相关原则
区分系统调用错误和业务失败远程调用失败不代表下游系统没有接收请求更不能做为业务失败依据需要严格区分系统调用错误和业务失败。可重试任何一行代码执行时都有可能因系统重启而中断所以需要支持可重试。异步处理必须增加核对最终一致性离不开恢复重试策略也需要有系统间数据核对用于及时发现数据不一致同时在核对时需要增加处理时效的监控及时发现长时间未处理成功的数据。
二 API设计相关设计原则
1 水平越权控制
API设计时需要考虑防范水平越权。目前我们的做法是从前端到后端每层都需要进行越权校验。通过从接口设计层面防控避免某层出现疏忽导致越权的事件发生。
2 接口幂等控制
调用方必须提供用于幂等控制的参数为了控制幂等同一个请求的幂等参数不变。在血泪史上由于接口不幂等导致的问题太多了这个目前基本上已经成了部门在接口设计上的共识。
3 兼容性原则
API升级和调整需要兼容老的版本。为了保证接口可以升级我们对接口的设计就会存在比较高的要求譬如接口参数中不能使用枚举不能使用Java基础类型等同时也要求接口设计需要具备一定前瞻性和通用性尤其对于面向业务领域的接口设计更要求对该领域的业务知识有比较多的了解。
当然还有一些原则在《Java开发手册》中已有叙述这里就不在赘述。
三 总结
本文介绍了我们在系统设计和开发实际场景中总结出的一些原则通过这些原则的总结和沉淀可以在后续出现同类问题时做出相对正确的选择避免重蹈覆辙。另外通过在大的原则下进行具体化和明确化能够让大家容易达成一致让架构方案更容易落地不走偏。
另外无论是在生活上还是工作上建议多从成功的经验或者失败的教训中去总结形成自己的原则丰富自己的决策系统。这是《原则》这本书给我带来的一个比较大的启发。
原文链接
本文为阿里云原创内容未经允许不得转载。
