提到现代应用架构，我们很自然地想到云原生技术，具体包括K8s 、DevOps和微服务这”三驾马车“。那么，到底什么是现代应用架构？现代化应用架构的背后驱动是什么？从底层基础设施层面来看，发生了哪些变化……只有理清各种概念，才能实现横向整合、纵向扩展目标，进而走向现代应用架构变革之旅！
如何理解现代应用架构？
关于现代应用架构，业界有一个标准概念，那就是应用现代化。通常是指，通过微服务和应用编程接口（API）来实现松散耦合，以连接相关服务。现代应用架构与传统单体式应用架构完全不同，不管是开发、交付还是服务交互模式，都变得更敏捷，更适用于云以及数字化环境。
▲在F5资深架构师林静
“现代应用架构，并不是要创造一种新应用，而是让应用能够满足现代化的业务要求。” 在F5资深架构师林静看来，现代应用架构可以简单地理解为与云原生对应，特别在多云环境下，应用的发布、开发和运行，都与以往架构不同，其中会涉及到云、容器，包括Kubernetes这样的编排技术。
那么，现代应用架构从无到有，是如何产生的呢？本质上是业务和技术的双重驱动！企业为了推动业务发展，会选择更前沿、更能符合用户需求的服务，比如：会通过引入数字技术，提高业务反应速度，提升用户体验。这意味着，底层技术架构必须有效支撑上层的业务变化，从应用需求的角度进行变革。
简单理解，现代化应用架构需要依赖底层环境去运行，而底层环境不只是一个组件，而需要一个横向贯穿的平台能力。在国内，有些企业在提“全栈”概念，事实上，全栈强调的是整个业务的贯穿能力，包括业务的对接、业务需求的理解到业务成功上线、交付，再到后期的运维管理，是整体的横向打通能力。
说白了，平台能力不只是一个概念，要在底层有一系列的工具支撑，真正服务于业务场景，满足各种技术要求。
底层架构和上层应用如何打通？
问题是，打造平台级能力，以F5为代表的企业需要做些什么？
“企业业务能力需要横向评估，但做事情的时候需要纵向互相支持。” 林静强调，现代化应用架构在底层基础设施层面要考虑方方面面，包括API网关、流量网关等等。
值得一提的是，软负载网关是企业的关键基础设施。单从应用角度来讲，在现代业务环境下，网关或者是负载均衡类、反向代理类技术都在提升。比如：当应用进入虚拟化、容器化的场景下，部署路线完全不同。
企业自己在做私有云的时候，负载均衡已经变成云上的标准ELB（弹性负载均衡），然后从传统的ELB演化成NLB（网络型负载均衡）、ALB（应用型负载均衡）。但本质变化是，不再强调底层技术表现，而把它变成私有云上的一种服务能力。这个底层服务能力到底落在哪里？F5为用户提供的平台级方案是，在上层用户表现出LB的服务，但底层有F5、NGINX，以及其他的框架。并且，这些底层的技术，用户不可见，用户看到的只是服务对象。
到了PaaS或者Kubernetes容器化环境以后，反向代理、负载均衡位置进一步提升。比如：针对Kubernetes标准的Services的具体表现是可访问的对象，而这背后涉及的技术就是服务代理与负载均衡。当企业发布一个简单的部署，或者发布一个服务应用的时候，系统默认会产生一系列相应的服务代理做支撑。而不像之前，需要申请一个服务做负载均衡，服务本身已经带上负载均衡、网关等能力了，底层位置越来越趋近于上层应用。
如何利用可复用技术支撑现代架构？
需要重点强调的是，构建现代应用架构，并不是一切都要推倒重来，重新造轮子，而是可以借助一些可复用的技术，实现平台能力的迭代升级。
例如，某个金融客户对于软负载技术的应用路径如何设计？
该企业曾经拥有一个小规模的团队，主要负责处理类似负载网关技术和软负载技术的问题，但其实这只是他们的兼职工作。因为，在企业发展早期，他们意识到这些工作的重要性，但并没有将其提升到一个高度。随着业务的发展，他们发现软负载技术越来越重要，于是专门成立部门，把这一技术纳入到整个开发中心体系中，他们希望这个团队负责的技术产品能在未来能支撑全行所有的运营中心的技术应用。
具体操作是怎么一步步进行实践的呢？
第一步，从具体场景入手。他们选择了一个切入点，基于K8s平台建立一些区域。在这个区域中，他们需要解决一些与K8s入口控制器相关的问题，因为这些问题和场景非常具体，没有涉及到复杂的传统应用间的关系。所以，他们决定在这个位置上先引入负载技术，基于团队所负责的底层网关技术，打造入口控制器。
第二步，延伸到更广阔的SLB领域。有了之前的基础，企业开始深化工作，进一步完善底层的数据面的能力，然后扩展到其他方向。在扩展的第二个阶段，除了K8s区域外，企业早期在单元化或负载均衡中部署了大量的网关或流量网关，以及负载均衡的网关，这些技术在之前可能非常散乱，版本和产品技术各不相同。他们希望利用在数据面沉淀出来的能力，进行进一步的扩展，包括适应全新在虚拟机、非K8s环境下的单元化网关等需求，所有这些都希望基于统一的技术来实现。
第三步，在完成SLB领域的工作后，会进一步扩展到业务路由，也就是进入API网关领域。在这个过程中，企业会在大量的SLB分析之后，提升流量网关、单元化网关和业务路由整体控制面的成熟度。这时候，企业在标准的现代化K8s平台中，以及传统的区域中的大部分网关类技术已经被统一，表现出比较好的管理和控制能力，日常管理工作相对成熟。
最后一步，将平台能力向业务层面进一步延伸。很多金融企业的API网关可能会比较混乱、分散，比如：业务研发部门基于底层技术，用JAVA语言开发了一个简单的业务网关。但是，每个团队都有自身的需求和观念。在这种背景下，前面的工作沉淀下来后，延伸到业务网关就变得可行了。因为到业务网关层面，只是业务语言和需求的转化，底层的核心技术没有太大变化。所以，这种能力可以进一步延伸到业务层面。
由点到面，由局部变统一。这家金融企业的架构变革之路，让我们看到“现代化应用架构”并不是一个“重复造轮子”的工程，而是由技术到业务、由业务到技术的双向驱动。当企业有足够的技术沉淀，然后把这种技术能力向业务层面持续推进，同时在深度上提供更好的业务支持，满足运营需求，这应该就是很多企业所追求的“基础设施与平台能力互为要求、共同支撑业务”的理想境界。
