经验啦

  1. 首页 > 生活百科 > 科技 > >

华为|如何写出一篇好的技术方案？( 二 )

华为数字化转型















【华为|如何写出一篇好的技术方案？】


























图不用很细（比如加工比较复杂我们可以简单写**加工） ， 但是要能看到全貌 ， 具体的每个模块如果需要展开的 ， 那么在对应的详细设计中体现即可 ， 在这里我们关注的是整体； 接口如有归属不同的应用要标明； 数据存储介质不同要标明； 数据流转的箭头要清晰明确； 数据加工计算的输入和输出要体现 ， 同时要体现加工的运行环境（比如到底是 odps 计算还是内存计算 ， 内存计算的话是在那个应用） 。模型设计 讲到数据模型设计 ， E-R 图是必不可少的 ， E-R 图应该包含以下信息： 每个领域对象 ， 如果要持久化 ， 都有表来存储 。 我们设计完 ER 图的时候 ， 应该根据这条原则做一番检查 ， 避免漏掉一些表 。 在大型项目中 ， 漏掉表是很常见的事情 ， 应尽量避免 。领域对象之间的关系 ， 如果要持久化 ， 都要在表结构中体现 。 这种体现 ， 可能是 code 字段 ， 可能是外键 ， 可能是中间表 。 我们设计完 ER 图的时候 ， 也应该根据这条原则做一番检查 ， 避免漏掉一些关系 。 在大型项目中 ， 漏掉关系更是司空见惯 ， 应尽量避免 。清晰定义的表名 。 设计 ER 图的时候 ， 就要设计出清晰定义的表名 。 清晰定义的表名 ， 可以帮助大家理解 ER 图 ， 可以帮助大家映射回领域对象及其关系 。 在后续的设计和实施中 ， 将沿用这个表名 。清晰定义的字段名、字段类型、字段长度和枚举值 。 很多同学容易忽略这点 ， 他们往往清晰定义了表名 ， 却没有重视表的字段 。 认真去做的时候 ， 会发现 ， 这里面有很多工作 。 例如 ， 字段名是否合适 ， 用什么类型好 ， 字段长度多少合适 ， 是否有枚举值等等 ， 都需要一一斟酌 。 如果这点做好了 ， 在实施的时候 ， 可以避免很多麻烦 ， 甚至避免返工 。对外依赖提前确认 技术方案 1：需要依赖缓存、分布式调度中间件、消费外部的消息 ， 但是没有把对应的中间件使用方式、数据格式贴出来 。技术方案 2：需要依赖缓存、分布式调度中间件、消费外部的消息 ， 将缓存接入的方法对应的缓存 key-value 设计写清楚 ， 将分布式调度中间件接入所需要准备的依赖项梳理好 ， 将外销消息对应的 topic 和数据格式列清楚 。两个方案对比好坏其实很明显 。 如果一开始我们在技术方案里面将外部依赖确定好 ， 那么我们在开发的时候就一马平川 ， 反之如果外部依赖都不确定的情况下就进入到开发 ， 那么返工的概率将大大增加 ， 从而降低我们的工作效率 。那么 ， 对外的依赖有哪些以及我们应该要确认什么信息呢？下面列举了一些常见的依赖情况： 外部 hsf 依赖：需要确认对应 hsf 接口的类、方法、version ， 以及二方包（也可使用泛化调用）； 外部消息依赖：需要确认消息的 topic、数据格式； 分布式调度、缓存等中间件：当前应用是否接入过该中间件 ， 未接入需要去到官网确认接入文档 ， 接入的话需要确认是否可以复用接入逻辑 。内部前后模块依赖层次结构 模块依赖层次从高到低分为： 领域依赖（如交易依赖商品） 应用依赖（如 cntcp 应用依赖 cngfc 应用） 接口依赖（如滚存看板查询接口依赖于锁接口渠道集接口） 我们举接口依赖的例子来看：一共三个接口分别是滚存看板查询接口、锁接口、渠道集接口 ， 滚存看板查询接口依赖于锁接口和渠道集接口 。技术方案 1 目录层次：滚存看板查询接口、锁接口、渠道集接口； 技术方案 2 目录层次：锁接口、渠道集接口、滚存看板查询接口 。很明显 ， 技术方案 2 是更加合理的 ， A 依赖于 B 那么 B 应该先做 。我们在写技术方案的时候 ， 要考虑什么应该在前什么应该在后 ， 而不是想一步写一步 。 要有一个清晰、有序的结构 ， 不然别人看起来就会是杂乱无章的 。一个模块里面应该有啥 下面列出一个技术方案的模块里面应该要写哪些东西 ， 供参考： 1、具体的接口定义 要求：实现一个飞机运力合同查询接口 ， 入参为运力大区 技术方案 1： 入参：{\"area\": \"南美\"出参:{\"date\": \"***\" 技术方案 2： 方法名：CapacityService.queryPlan入参：{\"cnArea\": \"南美\"出参:{\"date\": \"***\" 技术方案 2 是更好的 ， 为什么？测试、前端 、后续要接手该接口的人都能够一下子找到你的接口并清楚知道输入输出是什么 。 另外 ， 1 和 2 的入参一个 area 一个 cnArea ， 那么到底哪个更对呢？这里由于系统中在用的都是 cnArea ， 固沿用 cnArea 是对的（一致性减小沟通成本） 。这里总结对接口定义有几点要求： 完整的类和方法名 入参字段如果系统中已有 ， 那便沿用；如果没有 ， 那么英文的描述需要准确（可同产品业务商榷） 出参字段要求同入参 2、详细的时序图 要求：实现一个学生信息查询接口 。技术方案 1：写出查询结果中执行的相关步骤 。step1. 入参校验step2. 查询A表step3. 对A标返回结果做校验step4. 查询B表······ 技术方案 2：在 1 的基础上使用时序图表达出来 。推荐使用技术方案 2 ， 好处是尽管内容相同但是时序图能够更直观地看到层次、数据流转等信息 。除了以上比较基础的 2 点 ， 我觉得的还有一些要点： 数据加工的详细图（如有）——同样推荐用图的形式可以更直观 消息设计（如有） ， 明确消息生产方、消费方、tps、数据结构 自测用例（推荐） ， 比较重要的功能点构造一些自测用例 ······ 技术选型分析 要求：实现一个定时任务 ， 定期将过期的数据删除 。技术方案 1：使用 spring 自带的定时器进行数据清除 。技术方案 2：使用分布式调度中间件（如 schedulerx）进行定时过期数据清除 。乍一看好像都能实现 ， 但仔细对比两个实现方式之后我认为大部分人还是会选择技术方案 2 ， 为什么？下面列出一些在选择技术方案时考虑的点 。安全生产 安全生产包括几个部分 ， 包括且不限于下面几个部分 监控 对账 灰度方案 数据隔离 兼容性评估 发布流程 我们举一个例子 。需求：在消费者收货成功时触发对商家的结算 。技术方案 1： ， 写了一堆如何触发结算、如何更好地支持后续的可扩展性； 技术方案 2： ， 写的方案可扩展性没有技术方案 1 高 ， 但是做好了未触发结算的监控、触发结算之后的对账 ， 并设计好了对应的报表防止出现资损 。其实这也是我们在技术方案中可能会忽略的一点——埋头于代码结构如何如何的好 ， 但是有些东西其实是要比单纯的代码更重要 。 就比如风险控制 ， 完备的监控、不可缺少的对账是保障公司资金安全 ， 更是保障我们自己绩效的工具（此处应有表情） 。那么对于监控、对账的具体要求是什么呢？我认为有以下几点： 监控： 监控目标：写清楚监控的是什么内容 监控点：如通过打印日志监控 ， 那么日志打印在哪个类的哪个方法 监控触发：是通过 sunfire 采集触发还是其它 ， 如果是 sunfire 采集最好能把监控项地址贴出来 监控订阅人：监控告警需要的订阅人 监控触发后的解决方法：如果发生异常该如何解决？如手工触发结算 对账： 对账目标：写清楚对账是为什么 对账方式：写清楚是怎么对账的（如通过 odps 天级定时任务 ， 履行单上的关务资源 code 和日志表中关务 cp 回传报文的关务资源 code 对比要一致 ， 不一致的形成某个数据集 ， 通过锦衣卫-资损风险平台配置） 对账告警订阅人 对账异常之后的解决办法 还有其它几个部分也补充说一下： 灰度方案 ， 包括但不限于： 多方前置准备 灰度切流开关设计 灰度切流节奏 异常应对 向前兼容性 ， 包括但不限于： 接口的向前兼容：尤其是对外的接口 数据结构的向前兼容：如不能随意改变字段的存储类型和格式 环境隔离： 如有租户隔离预发线上隔离的情况需要考虑数据 发布流程 ， 包括但不限于： 发布计划 检查项列表 发布流量监控 作者 | 忠武 原文链接：http://click.aliyun.com/m/1000345004/ 本文为阿里云原创内容 ， 未经允许不得转载 。

相关经验推荐


上一篇：手机辐射|618换机季，我为什么又一次选择了品牌台式机？华硕天选X主机评测

下一篇：英特尔|游泳也能感受到美妙的音乐，Sanag塞那A9S骨传导蓝牙耳机轻体验