互联网架构发展

单体应用架构

简单实⽤、便于维护，成本⼜低

优点：

  • 项⽬前期开发节奏快，团队成员少的时候能够快速迭代
  • 架构简单：MVC架构，只需要借助IDE开发、调试即可
  • 易于测试：只需要通过单元测试或者浏览器完成
  • 易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动

缺点：

  • 随着不断的功能迭代，单个项⽬过⼤，代码杂乱，耦合严重，开发团队逐渐壮⼤以后，沟通成本变⾼， 如：代码从编译到启动耗时达到 3-5 分钟
  • 新增业务困难：在已经乱如麻的系统中增加新业务，维护旧功能，⼀脚踩进去全是不可预测 的问题。新⼈来了以后很难接⼿任务，学习成本⾼，需要⼤概 ⼀周时间才能上⼿开发
  • 核⼼业务与边缘业务混合在⼀块，出现问题互相影响，如：⼀个临时活动流量猛涨，机器负载升⾼就会影响正常的业务服务

单体应用架构
image.png

垂直应用架构

为了避免上⾯提到的那些问题，开始做模块的垂直划分

核⼼⽬标：

  • 业务之间互不影响
  • 在研发团队的壮⼤后提⾼效率，减少之间的依赖。

image.png

优点：

  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进⾏优化
  • ⽅便⽔平扩展，负载均衡，容错率提⾼
  • 系统间相互独⽴，互不影响，新的业务迭代时更加⾼效

缺点 ：

  • 服务之间相互调⽤，如果某个服务的端⼝或者ip地址发⽣改变，调⽤的系统得⼿动改变
  • 搭建集群之后，实现负载均衡⽐较复杂，如：内⽹负载，在迁移机器时会影响调⽤⽅的路 由，导致线上故障
  • 服务之间调⽤⽅式不统⼀，基于 httpclient 、 webservice ，接⼝协议不统⼀
  • 服务监控不到位：除了依靠端⼝、进程的监控，调⽤的成功率、失败率、总耗时等等这些监 控指标是没有的

SOA应⽤架构

SOA (Service-Oriented Architecture)，即⾯向服务的架构
根据实际业务，把系统拆分成合适的、独⽴部署的模块，模块之间相互独⽴（通过Webservice/Dubbo等技术进⾏通信）。

优点：分布式、松耦合、扩展灵活、可重⽤。
缺点：服务抽取粒度较⼤、服务调⽤⽅和提供⽅耦合度较⾼（接⼝耦合度）
image.png

微服务应⽤架构

SOA架构的⼀种拓展，这种架构模式下它拆分粒度更⼩、服务更独⽴

强调的⼀个重点是“业务需要彻底的组件化和服务化”

image.png

微服务架构的优点: 微服务架构和微服务
微服务很⼩，便于特定业务功能的聚焦 A B C D
微服务很⼩，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作⼀定程度解耦，便于实施敏捷开发
微服务很⼩，便于重⽤和模块之间的组装
微服务很独⽴，那么不同的微服务可以使⽤不同的语⾔开发，松耦合
微服务架构下，我们更容易引⼊新技术
微服务架构下，我们可以更好的实现DevOps开发运维⼀体化；
微服务架构的缺点
微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂；
微服务架构下，分布式链路跟踪难等；

相关概念

服务注册与服务发现

服务注册：
服务提供者将所提供服务的信息（服务器IP和端⼝、服务访问协议等）注册/登记到注册中⼼
服务发现：
服务消费者能够从注册中⼼获取到较为实时的服务列表，然后根究⼀定的策略选择⼀个服务访问

image.png

负载均衡

熔断

描述：在微服务架构中，如果下游服务器因访问压力过大而响应过慢或失败，上游服务为保证系统整体可用性，暂时切断对下游服务器的调用。

链路追踪

对⼀次请求涉及的很多个服务链路进⾏⽇志记录、性能监控

API网关