软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
SOA面向服务架构:是一种软件体系结构,应用程序的不同组件通过网络上的通信协议向其他组件提供服务。SOA使用WebService进行通信。
微服务架构:从SOA架构发展而来,相比于SOA,服务的粒度更小。微服务使用REST进行通信,相比于SOA更轻量级。
Nginx:高性能、高并发的web服务器;功能包括负载均衡、反向代理、静态内容缓存、访问控制;工作在应用层
LVS: Linux virtual server,基于集群技术和Linux操作系统实现一个高性能、高可用的服务器;工作在网络层
Haproxy:
Apache:
Tomcat,Apache,Jboss,WebLogic
SOA、微服务、spring boot,django
docker,kubernetes
memcache、redis等
zookeeper、etcd、Dubbo,Eureka
Netty,grpc、dubbo、brpc,Thrift,jsonrpc
kafka、rabbitMQ、rocketMQ、QSP
消息队列的应用场景:异步处理、应用解耦、流量削锋和消息通讯
storm、akka
hadoop、spark
cobar也是阿里开源的,在阿里系中使用也非常广泛,是关系型数据库的sharding + replica 代理
mysql、oracle、MongoDB、HBase
elasticsearch、solr
rsyslog、elk、flume
CAP、BASE。
分布式CAP理论,任何一个分布式系统都无法同时满足Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性) 这三个基本需求。最多只能满足其中两项。
而Partition tolerance(分区容错性) 是必须的,因此一般是CP,或者AP。
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结, 是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。
数据一致性通常指关联数据之间的逻辑关系是否正确和完整。
在分布式系统中,数据一致性往往指的是由于数据的复制,不同数据节点中的数据内容是否完整并且相同。
一致性还分为强一致性,弱一致性,还有最终一致性。
强一致性就是马上就保持一致。
最终一致性是指经过一段时间后,可以保持一致。
分布式事务是指会涉及到多个数据库的事务,其实就是同一数据库向分布式的扩展。目的是保证分布式系统中数据的一致性。
XA方案(2PC/3PC)
2PC(二阶段提交):准备阶段和提交阶段。
3Pc(三阶段提交):预备阶段(CanCommit),准备阶段(PreCommit)和提交阶段(DoCommit)。
TCC 方案(Try、Confirm、Cancel)
本地消息表
A 系统在自己本地一个事务里操作同时,插入一条数据到消息表;
接着 A 系统将这个消息发送到 MQ 中去;
B 系统接收到消息之后,在一个事务里,往自己本地消息表里插入一条数据,同时执行其他的业务操作。
如果 B 系统处理失败了,那么就不会更新消息表状态,那么此时 A 系统会定时扫描自己的消息表,如果有未处理的消息,会再次发送到 MQ 中去,让 B 再次处理;
A 会不断重发消息,直到 B 那边成功为止。
可靠消息最终一致性方案(RocketMQ)
A 系统先发送一个 prepared 消息到 mq,如果这个 prepared 消息发送失败那么就直接取消操作别执行了;
如果这个消息发送成功过了,那么接着执行本地事务,如果成功就告诉 mq 发送确认消息,如果失败就告诉 mq 回滚消息;
如果发送了确认消息,那么此时 B 系统会接收到确认消息,然后执行本地的事务;
mq 会自动定时轮询所有 prepared 消息回调接口是继续重试还是回滚?
最大努力通知方案
系统 A 本地事务执行完之后,发送个消息到 MQ;
这里会有个专门消费 MQ 的最大努力通知服务,这个服务会消费 MQ 然后写入数据库中记录下来,或者是放入个内存队列也可以,接着调用系统 B 的接口;
要是系统 B 执行成功就 ok 了;
要是系统 B 执行失败了,那么最大努力通知服务就定时尝试重新调用系统 B,反复 N 次,最后还是不行就放弃。
HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外)。也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
分布式锁,是指在分布式的部署环境下,通过锁机制来让多客户端互斥的对共享资源进行访问。
基于数据库实现
基于Redis实现
基于ZooKeeper实现
1、在分布式系统环境下,一个方法在同一时间只能被一个机器的一个线程执行;
2、高可用的获取锁与释放锁;
3、高性能的获取锁与释放锁;
4、具备可重入特性;
5、具备锁失效机制,防止死锁;
6、具备非阻塞锁特性,即没有获取到锁将直接返回获取锁失败。
1. Session复制
2. 粘性Session:当用户访问集群中某台机器后,强制指定后续所有请求均落到此机器上
3. 缓存集中式管理
消息队列( messagequeuing )使用消息将应用程序连接起来。
AMQP,即Advanced Message Queuing Protocol,
一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。
基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品、不同开发语言等条件的限制。
解耦、异步、削峰
kafka、activemq、rabbitmq、rocketmq
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。
SpringCloud是微服务架构下的一站式解决方案;Dubbo始终定位是一个RPC框架。
SpringCloud底层使用REST进行服务调用;Dubbo使用RPC进行服务调用。
在分布式环境中,许多服务依赖项不可避免地将会失败。Hystrix是一个通过添加延迟容忍和容错逻辑来帮助您控制这些分布式服务之间的交互的库。Hystrix通过隔离服务之间的访问点来实现这一点,停止跨级的级联故障,并提供备用选项,所有这些都可以提高系统的整体弹性。
资源隔离,服务隔离,服务熔断,服务降级,限流。
Zuul是Spring Cloud全家桶中的微服务API网关。
所有从设备或网站来的请求都会经过Zuul到达后端的Netflix应用程序。作为一个边界性质的应用程序,Zuul提供了动态路由、监控、弹性负载和安全功能。Zuul底层利用各种filter实现如下功能:
认证和安全 识别每个需要认证的资源,拒绝不符合要求的请求。
性能监测 在服务边界追踪并统计数据,提供精确的生产视图。
动态路由 根据需要将请求动态路由到后端集群。
压力测试 逐渐增加对集群的流量以了解其性能。
负载卸载 预先为每种类型的请求分配容量,当请求超过容量时自动丢弃。
静态资源处理 直接在边界返回某些响应。