从单体架构到分布式架构的演进

单体架构

通常来说，如果一个war包或者jar包里面包含一个应用的所有功能，则为单体架构

集群及垂直化

  • 按照业务维度垂直拆分成多个子系统，每个子系统由单独维护部署（包括数据库等）
  • 对Tomcat服务器进行集群部署，把堕胎Tomcat服务器通过网络进行连接组合，形成一个整体对外提供服务

SOA

SOA（Service-Orientend Architecture）面向服务架构。
把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，降低耦合，可以重用

微服务架构

针对可重用业务服务的更进一步优化，可以把SOA看成微服务的超集，多个微服务可以组成一个SOA服务

微服务和SOA区别

  • SOA关注的服务的重用性（服务的复用）及解决信息孤岛问题
  • 微服务关注解耦（降低耦合度）
  • 微服务更关注DevOps持续交付（微服务划分粒度更细，与容器化技术结合更紧密）

微服务拆分的粒度没有统一标准，需要在粒度和团队之间寻找平衡。粒度越小，服务独立性更好，但是管理更复杂

微服务架构的挑战

优点

  • 复杂度可控：一个服务只需要关注一个特定的业务领域，并通过定义良好的接口清晰表述服务边界
  • 技术选型灵活：解耦后可以结合业务特性自由选择技术栈
  • 可扩展性强
  • 独立部署：某个微服务发生变更时不需要重新编译部署整个应用
  • 容错性：故障隔离再单个服务中

挑战

边界上下文划分、数据库拆分、API交互、大量的微服务开发和维护、运维等

  • 故障排查：交互链路比较长、日志多、定位问题根源可能比较困难
  • 服务监控：需要对每一个微服务都实现监控，开销大
  • 分布式架构的复杂性：远程通信可能会由于网络延迟故障导致程序的复杂度增加
  • 服务依赖：各个服务之间会存在更多的依赖关系，需要考虑相关改变对不同服务的影响，使系统整体更为复杂
  • 运维成本：多个微服务的正常运行、扩容、故障处理、快速部署和统一管理等

如何实现微服务架构

微服务架构图

image.png

微服务架构下的技术解决问题

微服务治理，将服务之间的依赖转化为服务对服务中心的依赖。

  • 分布式配置中心
  • 服务路由
  • 负载均衡
  • 熔断限流
  • 链路监控

这个家伙很懒，啥也没有留下😋