终究怎样做架构设计 80后聊架构

相关文章：《 80后聊架构：终究什么是架构设计？ | 架构师之路 》

做了多年架构设计，很多人连架构设计的关键流程和步骤都不知道。

很多人确实上线了很多系统，也确实做了很多需求，但基本上都是毫有方法，全凭自己构想的在做架构设计。

总的来说，架构设计有四个大的步骤，其中第二个步骤最容易被大家疏忽。

画外音：他人写文章，都说最后一个步骤最关键，我就是不按套路出牌，说第二个步骤最关键。

步骤一：了解需求以及定义系统边界。

Understand the problem & Identify the scope of the system.

了解需求，外围是和产品确定配置要求，以及依据业务确定性能要求。

定义系统边界，外围是要明白系统哪些要做，哪些不做。

步骤二：也就是最容易被疏忽的一个步骤，调研已有的相似的系统。

Research on existing systems.

你做的系统，是业内独创吗？假设不是，看看相似的系统是怎样做架构设计的。参考成熟的打算，能让你的架构设计事倍功半。

步骤三：顶层设计。

high-level architecture design.

设计系统的关键组件，以及它们之间的交互形式。例如:

这里要蕴含系统架构的粗略图，以及成功外围需求的流程图。

步骤四：也是十分关键的一个步骤啊，处置关键矛盾迭代设计。

Refine the design.

(1) 顶层设计完之后，哪里是系统的关键矛盾？

我们要依据潜在的关键矛盾，细化与迭代顶层设计。

例如：你要做一个计数系统，对推文的阅读，转发，点赞，评论数启动计数。

(2) 假设关键矛盾假设是并发，1秒10万次？

那或者就要添加一些失望锁，异步，批量恳求，Copy On Write等奇妙设计，甚至就义一些分歧性。

(3) 假设关键矛盾是分歧性，不准许数据出错？

那或者就要添加一些互斥，校验，write-ahead logging等奇妙设计。

迭代设计，处置完一个关键矛盾，继续处置无所谓矛盾，直到一切的配置需求与性能需求获取满足。

这外面有个中央要留意：在第四步迭代设计的环节中，有或者会发现第三步顶层设计的毛病。这个时刻，或者要提升甚至颠覆第三步顶层设计。

这也是为什么，一些系统运转了几年，就要启动重构。现在的顶层设计曾经满足不了现有的业务需求了。在原有顶层设计基础上，处置不了关键矛盾了，那就重构顶层设计来处置。

这也是我十分推崇的两大外围架构设计理念：

这两个架构理念，我会在接上去的100个架构常识点里重复提及。

我们举个例子。

假设业务需求是：“我想做一个1万属性，100亿数据，每秒10万吞吐的分类信息平台，像58同城一样，2个月成功”。

(4) 如何来做架构设计呢？

第一步，探求配置需求，性能需求，确定系统边界。

分类信息的特点是什么？

招聘、房产、二手、二手车、黄页... 品类单一，帖子schema不固定...

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

帖子颁布，帖子阅读，帖子搜查（每个属性都或者被搜查）...

需求的性能要求是什么？

数据量渺小，吞吐量渺小，用户实时访问，恳求延时敏感...

第二步，调研相似系统的打算。

国外信息分类做得最好的应该是 Craigslist 了，网上调研一些相关的资料，可以了解到，其外围的一些关键设计点：

①如何品类裁减？

服务垂直拆分，数据垂直拆分...

②如何裁减属性？

应用 MongoDB 的 schema-free 个性...

③如何成功搜查？

早期应用 MongoDB 的索引，前期应用搜查服务...

④如何应答大数据量，高并发量？

数据水平切分，逻辑处置服务化，集群化，缓存降落数据库压力...

总之，经过调研，对已有的打算有个初步的了解。

第三步，架构顶层设计。

微观上，联合Craigslist的一些成熟通常：

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

第四步，依据关键矛盾迭代设计。

① 关键矛盾1：多品类帖子数据的分开存储，使得外围业务流程及其复杂，怎样解？

潜在打算：一致帖子中心服务IMC（Info Management Center）。

② 关键矛盾2：多品类帖子属性的分级，裁减与校验，怎样解？

潜在打算：一致分类治理服务CMC（Category Management Center）。

③ 关键矛盾3：大数据量，高并发，跨品类的多属性搜查，怎样解？

潜在打算：一致信息检索服务E-search。

这里，是一个架构设计环节的案例演示，关键用以说明设计流程。详细“1万属性，100亿数据，每秒10万吞吐的分类信息平台”的设计细节，详见后文的补充阅读资料。

回归今天话题，架构设计的四大步骤：

有人问，第二步自创已有成熟系统的打算，在别的架构设计方法中，没有看到过这个步骤呀？莫不是搞笑的吧。

我十分轻薄地申明，这个步骤十分关键，调研必定要多花期间。不行的程序员，看谁的代码都是屎；不行的架构师才会以为，我的打算最牛逼，他人的打算都是屎，但其实，自己原创的大局部打算才是屎。

坚持放开的心态，自创低劣的打算，是低劣架构师的外围质量。

“自创”这一点，任何不接地气的架构方法，都不会有人说。

补充阅读资料

上述案例架构设计打算细节，详见：《 1万属性，100亿数据，每秒10万吞吐，架构如何设计？ 》