前言
大多数技术同学对于自己的技术发展的认知还停留在学习了哪种技术，掌握了哪种开发框架，认为把技术学好就能成为一名架构师。
从技术层面来说是没有问题的，但是技术是服务于业务的，是用来解决现实生活的的问题的，如果你是位技术狂，那么请继续，否则我们还是以解决问题为核心。除了技术，还有很多需要我们去做的，比如与需求方的交流、提出解决方案的同时还要考虑成本、如何提高团队的开发效率、如何快速响应业务需求、如何提升系统的稳定性等等。
所以，我们要站在更高的视角来看待问题，尽量做到既能及时满足业务需求方的要求，又能保证系统的稳定性，又能提高团队的工作效率。
对于自己认知层面的不足，我们该如何提升呢？我们可以从三个角度出发：架构设计的认知、分析问题的认知以及能力边界的认知。
架构设计的认知
很多研发同学对架构设计的掌握和理解是缺少经验的，有的只能表达出基础层面的技术名词，落地没有经验，想要拔高也没有理论支撑。而一提到架构设计就会想到系统拆分，甚至觉得架构设计就是做系统拆分，但是对于为何要做系统拆分？做了拆分有什么好处？拆分是否能解决问题等等问题，都只能理解个表面，无法深层次地考虑底层设计的逻辑。
那我们该如何理解架构设计呢？是否有套路可以借鉴？我们可以用连续提问的方式来总结。
-
系统为何要做拆分？
核心：解耦。 将一个系统拆分成多个系统，增加了系统交互的复杂度，可为什么还要拆分？
-
系统为何要做解耦？
核心：高内聚低耦合，职责单一。 将原有系统的逻辑分割到拆分后的子系统中，虽然增加了系统交互的复杂度，但是各个子系统间的功能更加明确，职责也更加单一，这也需要我们规范好API的格式以及调用方式，使得复杂度在我们的可控范围内。
-
系统为何要职责单一？
核心：快速响应业务的需求变化，系统的迭代速度会大大提升，进而提高团队的开发效率。
-
为何要关注开发效率？
时间就是成本，每家公司都希望开发可以更快更好地完成业务方提出的需求，而架构拆分就可以快速响应需求，快速迭代出业务方的需求，大大提高开发效率。
总结：系统的拆分就是管理在技术上提效的一种手段。
分析问题的认知
在我们的日常工作中，开发同学在做系统设计时可能只考虑到把功能实现、问题解决了活就干好了。但是为什么没有得到业务方的好评、领导的认可呢？因为他们的关注点的不同。
- 业务方关注的是系统迭代后能满足市场的需求，他们关注的是系统提供的能力；
- 领导关注的是研发团队的开发效率有没有提高，关注的KPI与人效的管理；
同时也要考虑到公司或部门的战略，针对当下业务发展过程中产生的矛盾而提出系统设计原则，会让我们的技术更有价值，才会被更加认可。
研发效率的提升并不能仅靠增加人力来解决问题，还需要对原有的系统进行合理的边界拆分，提高研发效率，快速响应业务需求变化。
在我们做系统架构的时候，需要通过技术、成本、资源等考量来设计系统，解决现阶段的主要矛盾，也要对未来的演进发展有预估，为后续业务发展提供可靠保证。
能力边界的认知
站在架构师的角度，不仅需要掌握架构设计中的高性能、高可用、高扩展这些非功能性的设计方案，还要能驾驭全系统或者某一领域的业务。
如何形成对多系统层面带来的复杂度和解决问题的思考逻辑？这就要我们在日常的工作中养成总结归纳的好习惯，跳出自己的舒适区，多争取扩展自己能力的机会，同时还要形成自己的知识体系，沉淀自己的方法论，进而提高自己的认知能力。
架构师思维就是站在全局的角度来思考问题，包括时间和空间的全局。你还要能做到根据业务发展的阶段，通过技术、成本、资源等考量来设计系统，解决现阶段的主要矛盾，也要对未来的演进发展有预估。
