Java 系统架构的演变
Java 系统架构演变过程
单一应用 -> 垂直分布 -> 分布式服务 -> SOA(面向服务的架构) -> 微服务架构 -> Google Service Mesh
- 1. 单一应用
特点:
1. 结构简单,易于部署。
2. 网站流量很小时,一个应用部署所有功能。
3. 简化增删改查工作量的ORM框架是影响开发的关键。
问题:
1. 代码耦合,开发维护困难。(代码之间相互调用,引起错误。)
2. 无法针对不同模块进行针对化优化。
3. 无法水平扩展。
4. 单点容错低,并发能力差。(单点故障:一台挂了,整个挂了。)
使用场景:
传统行业内部开发,访问量小,适用集中架构。
互联网访问量大,不适合集中架构。
- 2. 垂直分布
访问量增大时,单一应用无法满足需求。为应对更高的并发和业务需求,需根据业务功能对系统进行拆分。
“用户中心”,“搜索服务”都要访问数据库增删改查,造成了代码重复,重复开发引起资源浪费。
“用户中心”,“搜索服务”相互独立,分摊流量。
优点:
1. 系统拆分实现流量分担,解决了并发问题。
2. 针对不同模块进行优化。
3. 方便水平扩展、负载均衡、容错率提高。
缺点:
系统间相互独立、重复开发工作多、影响开发效率。
- 3. 分布式服务
垂直应用越来越多,应用之间交互不可避免,抽取核心业务作为独立的服务,逐渐形成稳定的服务中心。
服务中心使得前端应用能更快响应市场需求。
分布式调用:提高业务复用即整合。
优点:
将基础服务进行抽取、系统间相互调用、提高代码复用率、提升开发效率
缺点:
系统间耦合度变高、调用关系错综复杂、难以维护
- 4. SOA 面向服务的架构
服务越来越多、容量的评估和小服务资源浪费的问题逐渐出现,此时需要增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。
用户提高机器利用率的资源调度和治理中心(SOA)是关键。
以前出现了什么问题?
-
服务越来越多,需要管理每个服务的地址。
-
调用关系错综复杂,难以理清依赖关系。
-
服务过多,服务状态难以理解,无法根据服务情况动态管理。
服务治理要做什么?
-
服务注册中心:实现服务自动注册和发现,无需人为记录服务地址。
-
服务自动订阅,服务列表自动推送,服务调用透明化,无需关心依赖关系。
-
动态监控服务状态监控报告,人为控制服务状态。
缺点:
-
服务间会有依赖关系,一旦某个环节出错会影响很大。(形成雪崩)
-
服务关系复杂,运维、测试部署困难,不符合DevOps思想。
- 5. 微服务架构
微服务特点:
-
单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责。
-
微:微服务的服务拆分粒度很小。例如:一个用户管理就可以作为一个服务。
-
面向服务:每个服务都要对外暴露Reset风格服务接口API。不关心服务的技术实现,做到与平台和语言无关,不限定技术实现,只提供Reset的接口即可。
- 6. Google Service Mesh
ServiceMesh本质上就是模式三~主机独立进程代理,它结合了模式一和模式二的优势,但是分布式部署运维管理开销大。Istio对ServiceMesh的架构、功能和API进行了标准化