转载

我是如何进行架构设计的

很多话只有经历过才能明白其中的含义，我觉得对。这里把我自己进行架构设计时的一些心得体会做个总结。

1.充分了解业务

所有的技术都是为公司业务发展服务的。公司的业务发展方向是由市场发展方向来确定的。没有哪家商业公司是根据程序员的喜好来的。所以你在进行架构设计前要充分了解业务及应用场景。项目是采用单体还是微服务很大程度上由项目所服务的业务场景及业务量决定的以及你项目组拥有的软硬件资源决定的。项目前期要多跟产品商务同事进行沟通，沟通的越充分，项目后期你就会越主动。

2. 预估一年内的业务增长量

为什么是一年呢，因为太久你就估不出来了，即便随便估一个也是不准的。伟大领袖毛主席不是说了吗，一万年太久只争朝夕。而且预估的量你要有自己的判断，不要完全听市场跟产品人员的。他们往往会夸大事实，对未来过于乐观，这样会导致你过度设计。另外所有的设计方案以及应用算法都是在某个数量级下讨论才有意义。所以你必须基于某个量级假设去设计你的技术方案。不然你就是耍流氓。最重要的是，你还要根据业务增长量来决定你申请多少硬件资源。

3. 了解组内开发人员技术栈

巧妇难为无米之炊，最终的项目落地，是要靠技术同事去实现。在做技术栈选型时要根据组内开发同事的现有水平来进行，比如组内大部分都是玩儿java的，这个时候就不要考虑python跟go了，即便他们可能更适合目前的项目。根据我的经验影响一个项目开发进度的，往往跟语言无关。另外虽然程序员都爱学习，但你要考虑是否愿意为他的成长买单。

4. 了解运维技术栈

有句话说的好，生孩子容易，养孩子难。运维同事就是负责养孩子的。我们在进行架构设计时不光要考虑开发的成本，更应该考虑后续的运维成本。甚至应该更多的考虑运维成本。假设有两套技术方案，方案A开发成本低，但是运维成本高，方案B开发成本高，但是运维成本低。毫不犹豫的选择B方案。因为后续一个项目大部分时间都是处于运维状态。

我是如何进行架构设计的

5. 数据建模

了解完业务场景，及组内成员的实力之后，该关起门来制定战术了。首先要对系统数据进行建模，他是整个系统的骨架，是对业务需求的抽象体现。这部分工作就搭建大楼的脚手架。你对业务的理解程度直接影响建模的效果，建模的效果直接决定架构的可扩展性。数据模型一旦建好，进入项目实施阶段之后就很难改变了。所以大家要慎重。