CAP定理

2000 年 7 月,加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2年后,麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后,CAP 理论正式成为分布式计算领域的公认定理。
微服务架构,分布式开发 - 图1
分布式系统的三个指标:

  • 一致性:Consistency
  • 可用性:Availability
  • 分区容错性:Partition tolerance

    一个分布式系统最多只能同时满足三项中的两项

一致性(Consistency)

一致性指 “all nodes see the same data at the same time”,即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致。

可用性(Availability)

可用性指“Reads and writes always succeed”,即服务一直可用,而且是正常响应时间。

分区容错性(Partition tolerance)

分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。

BASE 理论

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结,在 ACM 上发表文章提出 BASE 理论,BASE 理论是对 CAP 理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

基本可用(Basically Available)

基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。
电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。

软状态(Soft State)

软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现。

最终一致性(Eventual Consistency)

最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

ACID 和 BASE 的区别与联系

ACID 是传统数据库常用的设计理念,追求强一致性模型。BASE 支持的是大型分布式系统,提出通过牺牲强一致性获得高可用性。
ACID 和 BASE 代表了两种截然相反的设计哲学,在分布式系统设计的场景中,系统组件对一致性要求是不同的,因此 ACID 和 BASE 又会结合使用。

微服务需要满足三大指标

高可用

高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有:

  • 响应时间(Response Time)
  • 吞吐量(Throughput)
  • 每秒查询率QPS(Query Per Second)
  • 并发用户数等

响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。 吞吐量:单位时间内处理的请求数量。 QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。 并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量一定程度上代表了系统的并发用户数。

高并发

高性能

微服务架构需要解决四大问题

微服务最大的问题:网络不可靠

客户端如何访问服务

  • API网关

    服务与服务之间如何通讯

同步通信:

  • HTTP:Apache Http Client
  • RPC:Dubbo、gRPC、Feign

异步通信:

  • 消息队列:Kafka、RabbitMQ、RocketMQ等消息中间件

    如何管理服务

服务治理与发现:

  • Alibaba Nacos
  • Netflix Eureka
  • Apache Zookeeper

    服务挂了怎么办

  • Alibaba Sentinel

  • 重试机制

  • 服务熔断
  • 服务降级
  • 服务限流