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进行了标准化