很多话只有经历过才能明白其中的含义，我觉得对。 这里把我自己进行架构设计时的一些心得体会做个总结。
1.充分了解业务
所有的技术都是为公司业务发展服务的。公司的业务发展方向是由市场发展方向来确定的。没有哪家商业公司是根据程序员的喜好来的。所以你在进行架构设计前要充分了解业务及应用场景。项目是采用单体还是微服务很大程度上由项目所服务的业务场景及业务量决定的以及你项目组拥有的软硬件资源决定的。项目前期要多跟产品商务同事进行沟通，沟通的越充分，项目后期你就会越主动。
2. 预估一年内的业务增长量
为什么是一年呢，因为太久你就估不出来了，即便随便估一个也是不准的。伟大领袖毛主席不是说了吗，一万年太久只争朝夕。而且预估的量你要有自己的判断，不要完全听市场跟产品人员的。他们往往会夸大事实，对未来过于乐观，这样会导致你过度设计。另外所有的设计方案以及应用算法都是在某个数量级下讨论才有意义。所以你必须基于某个量级假设去设计你的技术方案。不然你就是耍流氓。最重要的是，你还要根据业务增长量来决定你申请多少硬件资源。
3. 了解组内开发人员技术栈
巧妇难为无米之炊，最终的项目落地，是要靠技术同事去实现。在做技术栈选型时要根据组内开发同事的现有水平来进行，比如组内大部分都是玩儿java的，这个时候就不要考虑python跟go了，即便他们可能更适合目前的项目。根据我的经验影响一个项目开发进度的，往往跟语言无关。另外虽然程序员都爱学习，但你要考虑是否愿意为他的成长买单。
4. 了解运维技术栈
有句话说的好，生孩子容易，养孩子难。运维同事就是负责养孩子的。我们在进行架构设计时不光要考虑开发的成本，更应该考虑后续的运维成本。甚至应该更多的考虑运维成本。假设有两套技术方案，方案A开发成本低，但是运维成本高，方案B开发成本高，但是运维成本低。毫不犹豫的选择B方案。因为后续一个项目大部分时间都是处于运维状态。
5. 数据建模
了解完业务场景，及组内成员的实力之后，该关起门来制定战术了。首先要对系统数据进行建模，他是整个系统的骨架，是对业务需求的抽象体现。这部分工作就搭建大楼的脚手架。你对业务的理解程度直接影响建模的效果，建模的效果直接决定架构的可扩展性。数据模型一旦建好，进入项目实施阶段之后就很难改变了。所以大家要慎重。
6. 讨论架构草图
经过上面那些步骤后，心中应该有个大概的架构草图了，这个时候应该把这份草图，讲给组内同事听，包括划分为哪些模块，语言编码规范，使用哪些具体技术。介绍架构草图的时候，要听大家的反馈。做到群策群力。只有方案得到大家的认可，实施起来才有效率。
7. 重视日志
上学时你可以不重视日志。但工作后必须重视。日志不仅是线上问题排查的根本，更是业务分析，系统监控的重要依据。好的日志应该是分类明确，职责清晰，格式工整的。比如某些日志是用来做系统运维的，有些日志是用来做监控的，有些是用于商务分析的。在做系统设计前一定要考虑清楚。否则后续运维将会事倍功半。
结论
以上是我的一些个人心得体会，并不一定正确。水无常形，兵无常势。大家要根据自己的实际情况来进行合理的架构设计。
最后优秀的架构都是根据业务的发展需要不断的改出来的。所以不要指望一步到位，每次架构调整能支持最近半年或者一年的量就OK。你需要做的就是让你的系统在不断的改进过程中一直保持高可扩展性，高可维护性。判断是否具备高可扩展性的一个方法是在需求增加和变动的时候，你是否狼狈。
