理解架构
维基百科:
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系，组件特性以及组件间关系的特性。软件架构可以和建筑物的架构相比拟。软件架构是构建计算机软件，开发系统以及计划进行的基础，可以列出开发团队需要完成的任务。
架构是这样定义的：
- 每个系统都由一个架构
- 架构由架构元素以及相互之间的关系构成
- 系统是为了满足利益相关者（Stackholder）的需求而构建的
- 利益相关者都有自己的关注点（Concerns）
- 架构由架构文档描述
- 架构文档描述了一系列的架构视角
- 每个视角都解决并且对应到利益相关者的关注点。
架构中的利益相关者：业务方、产品经理、客户、开发经理、工程师、项目经理、测试人员、运维人员、运营人员；理解各方的关注点和通电，并出架构解决这些关注点；
业务驱动与基础设施的进化推动架构的发展。架构需要解决需求的问题，业务需求的变化驱动着架构的进化。
基础设施的创新和开源价值的推动，一直在演进，到现在云原生时代，业务架构就需要基于云原生进行改造，如何基于云组件做适配，如何合理使用云的弹性、计算存储分离等功能也变得至关重要。而架构中最关键的是应该做到以不变应万变，这是以最终目标来看的：加速软件发布，减少整个软件生命周期中的资源投入（包括人力和最后软硬件资源等），通过管理复杂性、易变形和不确定性，为了简单高效的实现业务需求，确保在长期系统演进过程中，部分架构的变化不会对架构其它部分产生不必要的负面影响，让应用的易变部分能够频繁的变化。
为了处理好业务复杂性的业务领域建模，实现系统非功能性需求的架构领域的设计模式/风格至今也同样还是架构师的必备技能，只是应用在不同的基础设施上。不管什么时候，我们都强调架构在软件方面的可维护性、可扩展性、高可伸缩性，在组织架构方面的人员组织结构。我们的产品（软件）也必然是其（人员）组织沟通结构的缩影。
The hardest part of design is deciding what to design. – the design of design
架构需要设计，但是架构更是一个根据业务长期演化才能落地生根的。而最终架构不仅要服务于技术，更要服务于人。
非功能性需求的架构，xxx-abilities。
成为优秀的架构师
来自蔡超的三点建议：
1、坚持编码。架构师也是程序员，代码是软件的最终实现形态，停止编程会逐渐让你忘记作为程序员的感受，更重要的是忘记其中的“痛”，从而容易产生一些不切实际的设计。应该尽可能写代码，做测试，然后才是设计架构。
2、坚持学习。对于IT人而言忙碌已成为习惯，996也讽刺的变成了公司高效的标志。而实时上过度忙碌会导致你没有事件学习和更新自己的知识，进而逐渐落后。
3、用于关注技术上新的变化，同时更多思考的角度，重点是靠那些经历多年真正不变的技术和理念。
