ToB企服应用市场:ToB评测及商务社交产业平台

标题: 80后聊架构：毕竟怎么做架构计划？ | 架构师之路 [打印本页]

作者: 耶耶耶耶耶 时间: 2024-12-30 16:55
标题: 80后聊架构：毕竟怎么做架构计划？ | 架构师之路
《架构师之路：架构计划中的100个知识点》
2.毕竟怎么做架构计划？
做了多年架构计划，很多人连架构计划的关键流程和步骤都不知道。
  很多人确实上线了很多系统，也确实做了很多需求，但基本上都是毫无方法，全凭自己想象的在做架构计划。
  总的来说，架构计划有四个大的步骤，其中第二个步骤最容易被大家忽略。
  画外音：别人写文章，都说最后一个步骤最重要，我就是不按套路出牌，说第二个步骤最重要。
  步骤一：明白需求以及界说系统边界。
  Understand the problem & Identify the scope of the system.
  明白需求，核心是和产物确定功能要求，以及根据业务确定性能要求。
  界说系统边界，核心是要明确系统哪些要做，哪些不做。

  步骤二：也就是最容易被忽略的一个步骤，调研已有的类似的系统。
  Research on existing systems.
  你做的系统，是业内首创吗？如果不是，看看类似的系统是怎么做架构计划的。参考成熟的方案，能让你的架构计划事半功倍。
  步骤三：顶层计划。
  high-level architecture design.
  计划系统的主要组件，以及它们之间的交互方式。比方:
  利用机房，还是云？
  利用单体，还是微服务?
  要不要cache，要不要mq?
  用rdb，还是nosql?
  ...
  这里要包含系统架构的大略图，以及实现核心需求的流程图。
  步骤四：也是非常重要的一个步骤啊，办理主要矛盾迭代计划。
  Refine the design.
  顶层计划完之后，哪里是系统的主要矛盾？
  我们要根据潜在的主要矛盾，细化与迭代顶层计划。
  比方：你要做一个计数系统，对推文的阅读，转发，点赞，批评数进行计数。
  如果主要矛盾如果是并发，1秒10万次？
  那可能就要加入一些乐观锁，异步，批量哀求，Copy On Write等巧妙计划，甚至牺牲一些同等性。
  如果主要矛盾是同等性，不允许数据堕落？
  那可能就要加入一些互斥，校验，write-ahead logging等巧妙计划。
  迭代计划，办理完一个主要矛盾，继续办理次要矛盾，直到所有的功能需求与性能需求得到满足。
  这内里有个地方要注意：在第四步迭代计划的过程中，有可能会发现第三步顶层计划的缺陷。这个时间，可能要优化甚至颠覆第三步顶层计划。
  这也是为什么，一些系统运行了几年，就要进行重构。当初的顶层计划已经满足不了现有的业务需求了。在原有顶层计划基础上，办理不了主要矛盾了，那就重构顶层计划来办理。
  这也是我非常推崇的两大核心架构计划理念：
  其一，任何脱离业务的架构计划都是耍地痞；
  其二，架构不只是计划而来的，更是迭代与演进而来的；
  这两个架构理念，我会在接下来的100个架构知识点里反复提及。
  咱们举个例子。
  如果业务需求是：“我想做一个1万属性，100亿数据，每秒10万吞吐的分类信息平台，像58同城一样，2个月实现”。
  怎样来做架构计划呢？
  第一步，探究功能需求，性能需求，确定系统边界。

  分类信息的特点是什么？
  雇用、房产、二手、二手车、黄页... 品类繁多，帖子schema不固定...

  分类信息的典型场景是什么？

  帖子发布，帖子欣赏，帖子搜索（每个属性都可能被搜索）...
  需求的性能要求是什么？
  数据量巨大，吞吐量巨大，用户实时访问，哀求延时敏感...
  第二步，调研类似系统的方案。

  国外信息分类做得最好的应该是 Craigslist 了，网上调研一些相关的资料，可以相识到，其核心的一些关键计划点：
  怎样品类扩展？
  服务垂直拆分，数据垂直拆分...
  怎样扩展属性？
  利用 MongoDB 的 schema-free 特性...
  怎样实现搜索？
  早期利用 MongoDB 的索引，后期利用搜索服务...

  怎样应对大数据量，高并发量？
  数据程度切分，逻辑处理服务化，集群化，缓存降低数据库压力...

  总之，通过调研，对已有的方案有个开端的相识。
  第三步，架构顶层计划。

  宏观上，联合 Craigslist 的一些成熟实践：
  （1）业务垂直拆分；

  （2）微服务分层，集群化；
  （3）数据库程度切分；
  （4）缓存降压；
  ...

  大的方向基本就能把握住。

  第四步，根据主要矛盾迭代计划。
  主要矛盾1：多品类帖子数据的分开存储，使得核心业务流程及其复杂，怎么解？

  潜在方案：同一帖子中心服务IMC（Info Management Center）。
  主要矛盾2：多品类帖子属性的分级，扩展与校验，怎么解？

  潜在方案：同一分类管理服务CMC（Category Management Center）。
  主要矛盾3：大数据量，高并发，跨品类的多属性搜索，怎么解？

  潜在方案：同一信息检索服务E-search。
  这里，是一个架构计划过程的案例演示，主要用以说明计划流程。详细“1万属性，100亿数据，每秒10万吞吐的分类信息平台”的计划细节，详见后文的补充阅读资料。

  回归今日话题，架构计划的四大步骤：
  其一，明白需求以及界说系统边界；
  其二，调研已有的类似的系统；
  其三，顶层计划，界说核心组件与交互；
  其四，针对主要矛盾迭代计划；
  有人问，第二步鉴戒已有成熟系统的方案，在别的架构计划方法中，没有看到过这个步骤呀？莫不是搞笑的吧。
  我非常严厉地声明，这个步骤非常重要，调研一定要多花时间。不可的步伐员，看谁的代码都是屎；不可的架构师才会以为，我的方案最牛逼，别人的方案都是屎，但其实，自己原创的大部门方案才是屎。
  保持开放的心态，鉴戒良好的方案，是良好架构师的核心品质。
  “鉴戒”这一点，任何不接地气的架构方法，都不会有人说。
  补充阅读材料
  上述案例架构计划方案细节，详见：
  《1万属性，100亿数据，每秒10万吞吐，架构怎样计划？》
  4000字，慎入。

  ==全文完==
  如《接下来，预备干一件大事...》所述，后续我将以短视频+图文+直播+星球社群的情势，系统性的分享自己的架构师之路，架构计划中的100个相关知识点，欢迎感兴趣的童鞋关注。
  画外音：均免费。

  本日这是第二篇，码字有点慢，等不及的童鞋，先看短视频吧。

  短视频已经发布第三篇，《何时优化延时？何时优化吞吐量？》，这是大规模系统架构优化中，找主要矛盾，找优化点的架构师必备技能。

第3集：何时优化延时？何时优化吞吐量？

盼望大家能有收获。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)