应用架构图
上图来源于Processon上对Java应用架构绘制得比较全的应用架构图，代码实验室接下来会通过代码实验将整套应用架构从内到外的每个组件都整理学习分享出来给大家，希望大家多多支持。
什么是软件架构？
那么，什么是系统架构？
软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，达到软件本身访问增长目的的方式。
说到软件架构，很多人会认为软件架构就是一堆框架的组合，其实不对，软件架构本身是对于软件实体组织形式的阐述，使用框架的意义是快速完成软件架构设计，而不是取代软件架构设计，两者本质上是不一样的，它们的关系更像是设计图纸和所使用的原材料的关系。
拿上图来说，上图表达了软件的架构设计，同时也给出了每个部分所用的技术框架。我们试着从设计图纸的角度来解析一下上图，那么就会变成下面这样：
我标红色的组件则表示的是设计图纸的角色，举个例子，我们公司准备做一套XXX系统，要求该系统提供7X24小时稳定可靠的服务，能抗住大流量高并发等突发场景，支持可伸缩、可插拔、动态配置，高安全性，同时还要求开发和运维能够高效协同、快速迭代上线。那么我们要用到的软件架构组件有：网关（鉴权提高安全性）、注册中心、配置中心、服务追踪（及时告警）、微服务集群、异步处理、缓存、持久化存储、DevOps运维管理（开发-运维高效系统）等等。至于说图中的Spring Cloud Gateway、Nacos、Redis、SpringBoot...等等都只是完成这个软件架构设计图纸所使用的的原材料罢了，原材料可以有很多种，比方说微服务框架，我们可以用SpringCloud，也可以用Dubbo。
还有非常值得注意的是软件架构离不开软件开发团队的组织架构，这个组织架构是软件开发生命周期和软件运行生命周期的执行者。离开了组织架构，任何软件架构设计都是纸上谈兵，因为架构的核心生命周期就是架构的执行。
什么是组织架构？
软件架构若把软件看成虚拟的人，那软件架构实际上就是虚拟人的组织架构。架构拆分的原则，首先来源于业务自身的组织架构，软件架构要保持和业务组织架构的匹配关系。其实也只有软件架构和组织架构保持匹配，软件架构设计才能真正落地，软件架构师才能真正拥有工作的成就感、归属感。其次来源于软件开发团队自身的组织架构，没有组织架构的软件团队是不存在的，即便是现在流行的扁平化组织架构管理体系，组织架构依然是存在的，只是层级被压缩到较少程度而已。最后来源于用户的流量对软件本身的冲击，这其实是软件模拟人类行为的一种方式，一个人使用和成千上万人同时使用的业务场景都属于正常情况。如果软件开发团队的组织架构和业务的组织架构能一直保持高度一致，内部损耗就会达到最小，软件的架构会更简单，软件架构有效落地的可能性也会大幅度增加，软件模拟人的行为也会更加真实。
软件架构的进化
进化的含义是由一个物种变成另外一个物种，是本质的变化，比如物种由水生进化到了陆生等。
软件架构实际上是随着业务的变化而不断变化的。我们可以对业务生命周期进行拆分，分成核心业务生命周期和非核心生命周期，突出并精简业务核心生命周期，弱化非核心生命周期，从而使不同的业务生命周期可以在时间和空间上并行，提升效率。比如说我们设计的分布式存储系统，理论上通过增加机器就能无限提升存储能力和并发能力，也就节省了核心生命周期的开发时间，提升了开发人员的开发效率。
业务相当于基因，而架构呈树状延展则相当于细胞的分裂。
就好比每一个人，都是从一个细胞逐渐分裂出来的。一个细胞最终分裂成什么，起决定作用的不是分裂本身，而是它的基因。
基因决定了细胞最终会分裂生长成什么样的一个生命。比如一棵树从种子长成小树苗，再长成参天大树，这不叫进化，这叫生长。长成什么树是由树的基因决定的，不是架构。因为不管怎么拆分，业务的目标，也就是基因没有任何变化。如果一个企业的业务由制造商变成电商，这个时候业务就发生进化了。因为基因变了，业务已经完全不一样了，整棵架构树的含义就变了。该企业的软件架构就需要重新设计，而不能在原有的架构上修改，也就不存在架构的进化。
严格来说，只有业务才会进化，架构是支撑业务长大的。业务的核心生命周期相当于架构树的主干，主干没有变化，则说明没有变成一棵不同品种的树，因此只有架构的拆分不能叫作进化。随着架构拆分得越来越细，“树”长得越来越大，并行度越来越高，业务也就长得越来越大。
需要应用架构图原图的小伙伴可关注公众号“Seven的代码实验”回复“架构图”即可获得原图。
