Java Web架构演进与技术思考

Posted 陈书予

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java Web架构演进与技术思考相关的知识,希望对你有一定的参考价值。

✅创作者:陈书予
🎉个人主页:陈书予的个人主页
🍁陈书予的个人社区,欢迎你的加入: 陈书予的社区

文章目录

一、引言

随着互联网的发展,Web应用已经渐渐成为人们生活中不可或缺的一部分,Web应用从最初的静态页面到目前的动态交互应用,技术已经发生了翻天覆地的变化,而Java Web开发也在不断地演进。随着时间的推移和技术的更新换代,Java Web架构也经历了包括传统架构、分布式架构、云计算架构在内的多个阶段,而最新的微服务架构也正在成为Java Web开发的趋势。然而面对如此繁杂的技术选项,Java Web开发者们该如何选择合适的架构?本文将详细介绍Java Web架构的演进历程和技术选择。

二、Web架构演进概览

随着Web技术的不断发展,Web架构也在不断地演进。在过去的几十年中,Web架构从传统架构到分布式架构、再到云计算架构,不断进化,网络资源的利用效率也越来越高。

1.1 传统架构

最初的Web应用基于传统的单一服务器架构,后端处理和前端展示在一个服务器上完成,用户对Web应用的访问也是集中在该服务器上。这种架构模式主要适用于小型应用。

1.2 分布式架构

分布式架构是Web应用发展的趋势,它将Web应用分解成若干个模块,让每个模块都能运行在不同的物理或者虚拟服务器上,从而实现不同模块的分布式部署和运行。这种架构模式具有高可靠性、易扩展等优点,已经成为主流的Web应用架构模式。

1.3 云计算架构

云计算架构在分布式架构的基础上,又引入了云计算技术,将Web应用部署在云平台上,具备云平台和云服务的全部优点和能力,如自动化部署、高可用性、弹性扩展、数据安全等。

1.4 三个架构的对比

架构类型优点缺点
传统架构- 开发成本低;
- 易于部署和维护。
- 扩展性差;
- 性能瓶颈严重;
- 可靠性低。
分布式架构- 灵活性高,易于扩展;
- 性能好,可承受大流量;
- 故障容错能力强。
- 消息传递复杂,需要对网络通信和协议进行优化;
- 开发和设计难度较大;
- 需要涉及一定的分布式算法和分布式系统的知识。
云计算架构- 弹性扩容和弹性缩容功能,让系统更灵活和适应不同负载;
- 高可用性,提供容灾、备份、监控等功能;
- 可以实现快速开发和交付。
- 安全性需要更高的保证;
- 成本较高,需要更多的资源;
- 对系统性能及开发人员技术背景要求较高。

三、Java Web开发现状

Java Web开发面临着众多问题,如低性能、部署困难、维护复杂等。这些问题主要与Java语言、开发框架和Web服务器有关。

2.1 Java Web开发面临的问题

Java Web开发中存在的问题主要有:

  • 低性能:Java的内存管理机制使得其处理速度较慢,尤其是在高并发访问时。
  • 部署困难:Java应用程序的部署过程相对其他语言较为繁琐,需要配置Java运行环境,并保证各个库文件和类路径正确。
  • 维护复杂:Java的开发框架和Web服务器较多,每个框架的使用方式和技术细节各有不同,对开发人员及其维护人员的技能要求较高。

2.2 解决Java Web开发问题的技术

为了解决Java Web开发过程中遇到的问题,Java开发社区中出现了许多优秀的开发框架和技术,如:

  • Spring框架:提供了对Java应用的完整支持,包括Web应用、后端应用、RESTful服务等,是Java Web开发中最受欢迎的开发框架之一。
  • MyBatis:是一款数据库持久层框架,能够简化数据库操作过程,提高后台服务性能。
  • Hibernate:也是一款数据库持久层框架,提供了对象关系映射(ORM)功能,支持面向对象编程思想。
  • Tomcat:是Java Web服务器和Servlet容器,是目前应用最广泛的Web服务器之一。
  • Jetty:是一种嵌入式Java Web服务器,可用于开发端口工具、中间件、应用服务器等。

四、Java Web架构演进历程

随着Java Web开发场景的不断拓展和新兴技术的出现,Java Web架构也经历了多个阶段。

3.1 JSP + Servlet 架构

JSP和Servlet是Java Web开发中最早应用的技术,JSP(Java Server Pages)是Java语言编写的动态网页技术,可以生成标准的html页面,适合中小型网站开发;而Servlet是Java Web基础类库中的一种用于处理Web请求的类库,通过Servlet实现动态Web应用的处理和响应。

3.2 Struts 1.x 架构

在此基础上,出现了Struts 1.x框架,Struts框架基于MVC设计模式,支持自定义标签,通过XML配置文件定义业务逻辑和表单验证功能等,它充分利用了JSP + Servlet架构所提供的技术,提高了Web应用的开发效率和性能。

3.3 Spring MVC 架构

Spring MVC是目前Java Web开发中主流的Web应用框架之一,基于MVC设计模式,采用注解和面向切面编程(AOP)风格,在以提供了一种现代化的、基于注解的Java Web开发方法,不仅简化了开发流程,同时提供了强大的扩展能力,适用于开发中大型Web应用。

3.4 J2EE 架构

Java 2 Enterprise Edition(J2EE)是Sun公司推出的一组标准,包括EJB、JSP、Servlet等,可以提供全面的能力支持企业应用开发,J2EE服务器提供了一层可插拔的、基于组件的体系结构架构,更好地满足了大规模应用的复杂性和安全性要求。

3.5 Spring Boot 微服务架构

Spring Boot是一个基于Spring框架的快速开发Web应用的微服务架构,它采用约定大于配置的方式,避免了大量的XML配置文件和繁琐的环境部署,极大地提高了开发效率和运行效果。

3.6 以上架构的优缺点对比

架构类型优点缺点
JSP + Servlet- 简单易学,易于上手;
- 对于小型项目来说,可快速搭建简单Web应用。
- 不适合大型复杂项目;
- 前后端代码耦合度高,难于维护;
- 代码可读性差,难于分析和调试。
Struts 1.x- 模型-视图-控制器(MVC)架构明确清晰;
- 提供了灵活的拦截器机制;
- 可以与其他框架相结合使用。
- 代码冗余量大,重复代码多;
- 缺少现代化的特性和领域划分;
- 功能和扩展性有限制。
Spring MVC- 提供了灵活、强大的MVC模式支撑;
- 易于维护和扩展;
- 提供了一些非常有用的特性,如拦截器、数据绑定和校验等。
- 需要学习一些Spring的基础知识;
- 配置文件较多,容易出错;
- 适合中大型的Web应用。
J2EE- 可以实现高度粒度的组件开发;
- 提供了良好的安全性和事务管理能力;
- 可以充分利用现有的Java技术体系。
- 使用较为复杂,入门门槛较高;
- 配置和部署的复杂度较大;
- 开发效率低,需要多人协作。
Spring Boot微服务架构- 可以提高开发和部署的速度;
- 为微服务架构提供了良好的支持;
- 依赖管理和更好的自动配置能力。
- 学习曲线较陡峭,对框架的理解和掌握需要较高的水平;
- 适合中大型的项目,小型项目适用性不太强。

五、微服务架构的特点和优势

4.1 什么是微服务

微服务架构是一种用于开发单个应用程序的方法,其中应用程序可被视为一组微小的、独立的服务,每个服务都可由不同的程序员或团队开发,并可独立于其他服务运行。每个服务都实现一个小型API,可以使用任何编程语言编写,服务之间通过API相互调用。

4.2 微服务架构的优势

微服务架构具有以下优势:

  • 模块松耦合:微服务架构将一个大型应用程序分解成多个较小的服务,每个服务都互相独立运行,避免了不同模块之间的紧密耦合,便于系统的扩展和维护。
  • 容错性高:微服务架构中的每个服务都是独立的,运行在自己的进程中,即使其中一个服务失败,也不会影响其他服务的运行。
  • 快速迭代发布:微服务架构中的每个服务都有独立的代码库,因此可以独立地开发和测试,从而实现快速迭代发布。

4.3 微服务架构的特点和限制

微服务架构的特点包括:

  • 小型API:每个服务提供的API较小,可以用不同的编程语言编写,不需要统一的规范。
  • 自包含性:每个服务管理自己的数据,不使用其他服务的数据。
  • 自治性:每个服务是完全自治的,可以在没有其他服务的情况下独立运行。

微服务架构也有限制,如:

  • 运维复杂性:微服务架构中有多个服务,需要分别部署、配置和管理,带来普通单体服务的运维复杂性。
  • 分布式事物:每个服务都可以独立运行,导致分布式事务同步较为复杂。
  • 服务间的通信:微服务之间的通信需要一些技术留作支持,如RESTful API或gRPC。

六、基于Spring Boot的微服务架构实现

5.1 Spring Boot框架概述

Spring Boot是一个基于Spring框架的快速开发Web应用的微服务架构,它采用约定大于配置的方式,避免了大量的XML配置文件和繁琐的环境部署,极大地提高了开发效率和运行效果。

5.2 Spring Boot快速开发指南

Spring Boot快速开发指南介绍了如何通过Spring Boot快速开发Web应用,并包括创建一个简单的Web应用、配置Web应用环境、使用Spring Web框架、使用Spring Data框架等全面的介绍。

5.3 Spring Boot常用组件介绍

Spring Boot常用组件介绍了Spring Boot中常用的组件,如Spring Data、Spring Security、Spring AOP等,这些组件对于开发高效的Java Web应用十分重要。

5.4 基于Spring Boot的微服务实现

基于Spring Boot的微服务实现,即通过Spring Boot构建微服务框架,便于实现微服务架构模式下的模块化开发,具有高可用性和弹性扩展等特点。

七、微服务架构下的技术选型

6.1 服务注册与发现

随着微服务架构的发展,Java Web开发者需要选择合适的技术,如服务注册和发现、服务调用、服务网关、配置中心和消息队列等。

6.2 服务调用

服务注册和发现是微服务架构中的重要组件之一,其作用是将服务注册到注册中心,供其他服务发现和调用。

6.3 服务网关

微服务架构中,服务网关的作用是将所有的请求转发到相应的服务节点,通常使用API网关、Zuul和Spring Cloud Gateway等技术实现。

6.4 配置中心

由于微服务架构中需要管理大量的服务,因此配置管理变得很重要。常用的配置中心解决方案有Spring Cloud Config、ZooKeeper等。

6.5 消息队列

消息队列是基于发布订阅模式实现的,常用于微服务之间的异步通信。常用的消息队列有ActiveMQ、RabbitMQ和Kafka等。

八、Java Web服务的监控与容错机制

在开发Java Web应用时需要考虑监控和容错机制,以保证高可用性和稳定性。常用的监控解决方案有Spring Boot Actuator、ELK以及Prometheus等,常用的容错机制有Hystrix。

7.1 服务监控的意义

服务监控可用于发现性能瓶颈、检测错误和异常、优化系统运行、提高服务质量和稳定性等。

7.2 Spring Boot Actuator监控

Spring Boot Actuator是Spring Boot中的一个子项目,可用于监控应用程序的运行状况、启动时间以及内存使用情况等。

7.3 Hystrix容错机制

Hystrix是Netflix开源的一个容错机制组件,可用于保护微服务的数据和资源,具有限流、熔断和降级等功能,确保服务高可用性和稳定性。

九、Web服务的高可用架构设计

高可用架构设计是一个非常重要的问题,既可以保证应用程序的可靠性,也可以提高用户体验。高可用架构包括负载均衡、冗余备份、故障转移和容错机制等。

8.1 负载均衡介绍

负载均衡是指将请求分摊到多台服务器上,以实现负载均衡和提高响应速度。常用的负载均衡算法有轮询、加权轮询、随机等。

8.2 高可用架构设计方案

常用的高可用架构方案包括主从复制、主主复制、冗余备份和故障转移等,可用于实现容灾、远程备份、自动故障转移和负载均衡等功能。

十、Java Web应用的安全设计思路

Web应用安全是一个非常关键的问题,需要进行安全审计和合理的安全设计,以保证应用程序的安全性。常见的Web攻击方式有SQL注入、XSS攻击、CSRF攻击等,相应的防御措施包括数据加密、数据验证、CSRF令牌等。

9.1 Web应用安全问题概述

Web应用安全问题主要包括漏洞、安全策略、数据加密、数据验证等,需要采取相应的措施加以防范。

9.2 常见Web攻击方式和防御措施

常见的Web攻击方式包括SQL注入、XSS攻击、CSRF攻击等,需要采取相关的防御措施,如数据加密、数据验证、CSRF令牌等。

9.3 代码审计和漏洞扫描工具

代码审计和漏洞扫描工具可用于检测和更正Web应用程序中的漏洞和缺陷,例如Burp Suite、Acunetix等。

十一、总结与展望

10.1 Java Web架构演进的历史轨迹

Java Web架构是一个不断演变和发展的过程,从传统的JSP + Servlet架构到分布式架构,再到当前流行的微服务架构,Java Web技术在不断地发展和进步。在这个过程中,我们需要不断地学习和适应新的技术,以满足不断变化的需求。

10.2 Java Web技术的最新发展趋势

  1. 更加轻量级的Java Web框架:随着对性能和资源占用的要求越来越高,未来的Java Web框架可能会更加轻量级,提供更加高效的开发体验。

  2. 云原生应用:随着云计算和容器化技术的普及,未来的Java Web开发可能会更加注重云原生应用的设计和实现,以实现更加高效和弹性的运维。

  3. 人工智能技术的应用:未来的Java Web开发可能会更加注重人工智能技术的应用,例如自然语言处理、机器学习等,以实现更加智能化和便捷的用户体验。

10.3 Java Web开发的未来走向

  1. 更加轻量级的框架,提高开发效率:随着对性能和资源占用的要求越来越高,未来Java Web框架可能会更加轻量级,提供更加高效的开发体验。例如,目前已经兴起的Spring Boot框架就是一个很好的例子。

  2. 云原生应用,更加强调分布式架构:随着云计算和容器化技术的普及,未来的Java Web开发可能会更加注重云原生应用的设计和实现,以实现更加高效和弹性的运维。同时,随着企业业务的不断扩展,分布式架构的需求也将越来越高。

  3. 大数据和人工智能技术的应用:随着大数据和人工智能的发展,未来的Java Web开发可能会更加注重数据分析和处理能力,同时也可能加入更多与人工智能相关的功能,例如自然语言处理、机器学习等。

  4. 更加注重用户体验的设计:随着用户体验的重要性不断提高,未来的Java Web开发也将更加注重设计与实现高质量的用户体验。例如,响应式设计、单页应用等技术的应用将会越来越普遍。

高德客户端及引擎技术架构演进与思考

2019杭州云栖大会上,高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位、时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆,听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来,本文为其中一篇。

阿里巴巴高级无线开发专家宋照春在高德技术专场做了题为《高德客户端及引擎技术架构演进与思考》的演讲,主要分享了高德地图客户端技术架构沿着「上漂下沉」、「模块化、Bundle化」的思路演进所做的一系列架构升级中的经验和思考。

以下为宋照春演讲内容的简版实录:

主要分享三个方面的内容:

  • 融合
  • 架构治理
  • 动态化

一、三管齐下 深度融合

高德最初有两个端,车机版的高德导航,手机版的高德地图,两个团队,一个是2B,一个是2C,分别是汽车业务和手机业务。当时在引擎/技术上,分为离线引擎和在线引擎,但两个团队之间交流比较少,各自有自己的研发、产品和测试,而作为一款端上的APP,两块业务都需要有地图渲染、路线规划、导航以及定位等通用能力。从公司层面看,存在较大的重复建设,整体研发效率较低。

技术图片

于是我们做了一件事:利用技术手段,打通端上引擎,打造一套能同时支撑多端的APP能力。具体到执行层面,先从A团队拉一部分人到B团队一起建设,建设完之后再从B团队拉到A团队。在同时支撑好主线业务发展的情况下,通过一年左右时间,完成了引擎上的融合,做到同时支撑手机、车机以及开放平台。

技术图片

这样就从引擎的维度,实现了渲染、定位、规划和引导的统一。具体来说,我们的各大引擎有好多套代码,好几个开发团队,每个团队有各自的开发方式和开发环境(Linux,Windows,Mac OS)。各种开发环境,工程配置文件大量重复,修改非常繁琐。

为此,我们通过两种方法:

1.建立了一套构建系统Abtor,通过一个配置系统实现统一构建,能够同时支持多个子引擎,在构建集成效率上得到了很大的提升;

2.对基础库进行了整体重构,形成了一套涵盖了文件I/O、KV存储、多线程框架&异步框架、归档、基础容器等一系列标准能力的基础库,同时也做了引擎核心架构的统一。

技术图片

 

二、架构治理

通过引擎的融合同时支持多端,在研发效率上实现比较大的收益。而通过技术的抓手来实现团队的融合,对公司发展而言,这其实是更大的收益,团队融合的意义在于人才拉通和复用,组织效率得到了较大提升。

随着高德业务的快速发展,业务上持续扩品类,需求量激增,高德地图从最初的驾车导航,到后来的步行、骑行、摩托车导航等等,App所承载的业务发展非常快,而原有的架构治理模式的问题也逐渐暴露出来。

首先就是App的代码规模变得特别大。当时一个仓库达到了10G以上,由此导致的一个典型的问题就是编译慢,编译出一次安装包需要一个小时。伴随代码规模的另一个问题是团队规模快速增长。代码增长和大团队并行开发,最终导致合版慢,每次迭代,客户端合版需要2天。

代码膨胀导致的架构腐化问题特别突出,所以测试质量以及线上的质量有段时间也比较差。此外,从产品提出需求到上线,平均需要45天,版本迭代周期很长。

为解决以上架构问题,我们采取了三个手段:升级Native基础组件,搭建Native容器和页面框架,Bundle化分拆(微应用)。

下面重点介绍下页面框架和微应用。

页面框架主要借鉴和融合了Android和iOS的生命期管理机制。从高德地图App架构看,下层模块是一套标准地图,所有上层业务都要基于地图模块开发。为确保上层业务低耦合、一致性,我们设计了一个页面框架。

技术图片

如上图,左边的Activity是Android的系统页面控制器,右边的UIViewController是iOS的系统页面控制器,通过虚线连接比较,我们发现两端的页面状态设计基本相同。

所以,我们在设计自己的页面框架时沿用了这些系统页面状态,同时从命名上也保持一致,这样可以让Android和iOS原生开发的同学更容易理解和上手。

我们吸取了双端各自的优点。比如,Android端页面有四种启动模式,但是iOS 端并没有这些,我们就把Android的四种启动模式运用到了iOS端;iOS端有Present特性,但是Android端没有,那么也把这种特性融合到Android端的页面框架中;最后,还有一些小设计,比如Android的onResult设计,也可以借鉴融合到iOS端。

此外,我们还做了微应用,所谓微应用,首先是模块化,就是把大模块仓库大模块拆成一个个小的Bundle,除了实现模块化,还主要实现以下几个目标:

粒度:以业务为单位,以业务线为分组

编译:二进制级别的产物,可独立编译、出包时链接

依赖:松耦合,以“服务”为导向,不关心模块归属

而Native容器层面,要实现四个核心目标:路由管理、服务管理、UI生命期管理、微应用管理。

通过一年时间的Bundle化改造,高德地图单端App完成了300多个页面的建设,拆分了100多个Bundle。

从收益来看,总编译时间从原来的60分钟降低到了8分钟,合版周期从原来的3天降到1天,需求上线周期降到了1个月以内,线上质量和测试质量都得到了极大的提升,崩溃率从万分之八降低到十万分之八。

三、动态化

随着高德地图业务发展沿着扩品类、在垂直品类做精做细,景区、酒店、银行商铺、充电桩等个性化定制需求凸显,对前端展现提出了更高的要求,对“快速应变”要求也更高了。

实际上,在2015年,高德就开始做动态化。最早的时候业内就有React Native,团队做了技术调研,发现不能完全满足业务上的需要,尤其是性能方面。最后我们决定自研一套动态化技术。

具体来说,就是通过一个核心C++引擎,把两端业务(Android、iOS)用一套JavaScript代码解决,实现双端归一,Android实现业务动态化发布。

架构层面,最下面是高德App核心的地图引擎,我们在上面搭建了一套动态化应用引擎,通过C++来实现。应用引擎的作用是为了承上启下,上面承载动态化业务,下层完成地图引擎的直接打通。众所周知,GUI的核心是DOM树,所以应用引擎不但要实现和JavaScript引擎的整合,还要负责DOM树的核心逻辑计算。

其次,动态化的技术和前端Web技术一致:样式、布局。应用引擎负责完成样式的布局计算、DOM树Diff、事件生成。而GUI的绘制,通过Diff事件,交由原生的Android以及iOS去完成。这样,所有的GUI都是原生的组件。

在之上,我们搭建了一套前端框架,前端框架采用当前前端响应式框架做,前端框架之上又搭建了一套前端的UI卡片库和UI组件库,让上层业务能够更高效的开发。

而对于一些通过动态化的技术无法实现,或者性能上存在卡点的功能,我们就通过Native扩展能力来支撑,这样,完整的动态化的业务能够直接运行在Android以及iOS上。

技术图片

 

JS去执行代码之后,前端框架会产生虚拟的DOM树,最后提交到C++引擎,形成C++的DOM树。C++引擎去完成布局、样式计算,Diff计算,将每个节点的属性和坐标交给Android以及iOS,由Native来完成最终UI的渲染。

总体来说,动态化的特点:首先是它与主流前端框架融合,充分融合了大前端的生态;第二,性能、扩展性较好。因为采用C++实现整个核心逻辑,静态和动态的语言绑定技术,能够保证地图引擎的能力能够直接透出到上层,或者从上层能够直接call底层的C++能力;第三,多端归一和动态化,充分利用Native优势,接近原生Native体验。

动态化技术改造完成之后,双端不一致的问题降低了90%,开发、测试成本降低30%,发版周期从T+30到T+0。

最后,总结下高德客户端及引擎技术架构演进的几个重要阶段:第一个阶段,通过在线&离线引擎的融合拉通,让高德最核心的导航能力提到提升;第二阶段,在客户端发展成为“巨型”APP,代码量发展到超大规模的时候,通过架构治理,满足业务快速增长的诉求,解决大规模业务体量下的架构合理性问题,消除架构瓶颈;第三个阶段通过动态化的技术,实现多端归一,以及动态发版能力,为业务发展提供更大的助力。

技术图片

以上是关于Java Web架构演进与技术思考的主要内容,如果未能解决你的问题,请参考以下文章

从函数计算架构看 Serverless 的演进与思考

从函数计算架构看 Serverless 的演进与思考

大型网站技术架构的演进

微服务架构学习与思考(12):从单体架构到微服务架构的演进历程

技术架构演进流程(java)

技术架构演进流程(java)