Spring Cloud Alibaba 读书笔记_1：说在开头、架构演进

架构演进

• 单体架构
  • war 、 jar 包中包含一个应用的所有功能。
• 集群与垂直化（分而治之）
  • 横向增加服务器，把单台机器变成多台机器的集群。
  • 纵向进行业务拆分，减少业务耦合度，降低单个 war 包带来的伸缩性困难的问题。
• SOA（面向服务）
  • 核心目标为：把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务。
  • 主要解决的问题：
    • 信息孤岛
    • 共享业务的重用
• 微服务架构
  • 与SOA区别
    • SOA关注服务的重用性（复用）及消除信息孤岛的问题；微服务关注的是解耦，降低业务之间耦合度。
    • 微服务更多的关注在 DevOps 和持续交付上，因为微服务细化之后使得开发运维变得更加重要，因此微服务与容器化技术结合更为紧密。
  • 优点：
    • 复杂度可控：细粒度业务拆分，服务边界小，复杂度低。
    • 技术选型灵活：根据业务特性自由选择技术框架。
    • 可拓展型更强：根据单个微服务的性能要求和业务特点进行灵活拓展，比如增加单个微服务的集群规模，提升单个节点的硬件配置等。
    • 独立部署：每个微服务是一个独立运行的进程，所以可以实现独立部署，发布更加高效。
    • 容错性：当某个服务发生故障，可以使得故障隔离在单个服务中，其他服务可以通过重试、降级等机制来实现应用层面的容错。
  • 挑战：
    • 故障排查：一次请求可能经历多个微服务的多次交互，交互的链路可能较长，定位问题根源比较困难，
    • 服务监控：在一个几百个微服务组成的架构中，监控的开销会非常大，不仅要整个服务链路进行监控，还要对单个微服务进行服务监控。
    • 架构复杂性：微服务本身构建的是一个分布式系统，涉及服务间的远程通信，网络延迟及故障都说是无法避免的，从而增加了应用程序的复杂度。
    • 服务依赖：A -> B -> C，根据依赖关系，需要逐级进行更新。
    • 运维成本：快速部署、故障点排查、快速扩容等问题。
  • 微服务结构不是银弹，并不能解决所有的架构问题。
  • 架构的本质是对系统的有序化重构，使得系统不断进化。
    

Spring Cloud 主流实现

业内主流的微服务解决方案：

• Spring Cloud Netflix
  • Eureka：服务注册与发现
  • Zuul：服务网关
  • Ribbon：负载均衡
  • Feign：远程服务的客户端代理
  • Hystrix：断路器，提供服务熔断和限流功能
  • Hystrix Dashboard：监控面板
  • Turbine：服务实例的Hystrix监控信息的统一聚合
• Spring Cloud Alibaba
  • Nacos：服务注册与发现、分布式配置中心
  • Dubbo：RPC通信
  • Seate：分布式事务
  • Sentinel：流量控制与服务降级
  • RocketMQ：消息驱动