分布式系统 中间件

【。。。。。我只是想知道中间件是什么而已，结果。。。】
中间件=平台+通信，这也就限定了只有用于分布式系统中才能叫中间件，同时也把它与支撑软件和实用软件区分开来。
中间件技术能屏蔽底层操作系统的复杂性，我们对数据进行增删改查并不需要与底层操作系统的硬盘等各种指令打交道，我们只需要知道MySQL怎么使用，与MySQL进行交互即可。
在开始学习MySQL 数据库管理前你应该了解 PHP 和 HTML 的基础知识，并能简单的应用。
【要命】
【MySQL Router是mysql官方发布的数据库中间件，MySQL本身是数据库管理系统】【ROS是中间件+工具链】
【中间件就是一个中介，从各种单机、操作系统、各种编程语言的程序那里收集到信息，然后按需有序地把这些信息分发出去，并且有备份功能】【我大概是这么理解的，不保证准确无误。中间件似乎还有很多种类，涉及到的技术和难点也一大堆，就这样随便了解一下先】

分布式系统

分布式系统解决了什么问题？

第一个是单机性能瓶颈导致的成本问题，由于摩尔定律失效，廉价 PC 机性能的瓶颈无法继续突破，小型机和大型机能提高更高的单机性能，但是成本太高，一般的公司很难承受；
第二个是用户量和数据量爆炸性的增大导致的成本问题，进入互联网时代，用户量爆炸性的增大，用户产生的数据量也在爆炸性的增大，但是单个用户或者单条数据的价值其实比软件时代（比如银行用户）的价值是只低不高，所以必须寻找更经济的方案；
第三个是业务高可用的要求，对于互联网的产品来说，都要求 7 * 24 小时提供服务，无法容忍停止服务等故障，而要提供高可用的服务，唯一的方式就是增加冗余来完成，这样就算单机系统可以支撑的服务，因为高可用的要求，也会变成一个分布式系统。

---

我们主机的PC电脑，或者手机是集中式系统。我们把各种软件都安装在一台机子上，当我需要什么功能，我就从这台机子上去获取。
好处是，易于理解、方便维护，想要的东西我都放到了一个地方，东西好找啊。当然弊端也是显而易见的，如果这台机子崩了，或者硬盘坏了，那相当与整个系统就奔溃了，而且如果备份也是在这个硬盘上，那相当于招了灭顶之灾。
从进程角度看，两个程序分别运行在两个台主机的进程上，它们相互协作最终完成同一个服务（或者功能），那么理论上这两个程序所组成的系统，也可以称作是“分布式系统”。分布式系统的优点就是 如果一个主机坏了，还有别个主机能替他扛着。

使用分布式系统的另外一个理由是可扩展性。毕竟任何主机（哪怕是小型机、超级计算机）都会有性能的极限。而分布式系统可以通过不断扩张主机的数量以实现横向水平性能的扩展。大家也都了解到 Google 的服务器主机，大多是淘汰的二线机子拼凑的吧。

当然，这个两个程序可以是不同的程序，也可以是相同的程序。如果是相同的程序，我们又可以称之为“集群”。所谓集群，就是将相同的程序，通过不断横向扩展，以提高服务能力的方式。【就是一大堆机子做一样的事，类比GPU】

分布式系统的特点与难点

毫无疑问，分布式系统对于集中式系统而言，在实现上会更加复杂。分布式系统将会是更难理解、设计、构建 和管理的，同时意味着应用程序的根源问题更难发现。

设计分布式系统时，经常需要考虑如下的挑战：

• 异构性：分布式系统由于基于不同的网络、操作系统、计算机硬件和编程语言来构造，必须要考虑一种通用的网络通信协议来屏蔽异构系统之间的差异。一般交由中间件来处理这些差异。【中间件就是搞通信的？好像还得负责协调冲突？】
• 缺乏全球时钟：在程序需要协作时，它们通过交换消息来协调它们的动作。紧密的协调经常依赖于对程序动作发生时间的共识，但是，实际上网络上计算机同步时钟的准确性受到极大的限制，即没有一个正确时间的全局概念。这是通过网络发送消息作为唯一的通信方式这一事实带来的直接结果。【那就搞异步通信？】
• 一致性：数据被分散或者复制到不同的机器上，如何保证各台主机之间的数据的一致性将成为一个难点。【进程间通信也是要考虑这些】
• 故障的独立性：任何计算机都有可能故障，且各种故障不尽相同。他们之间出现故障的时机也是相互独立的。一般分布式系统要设计成被允许出现部分故障而不影响整个系统的正常使用。【can通信就是这样的】
• 并发：分布式系统的目的，是为了更好的共享资源。那么系统中的每个资源都必须被设计成在并发环境中是安全的。【进程通信的加锁】
• 透明性：分布式系统中任何组件的故障、或者主机的升级、迁移对于用户来说都是透明的，不可见的。
• 开放性：分布式系统由不同的程序员来编写不同的组件，组件最终要集成成为一个系统，那么组件所发布的接口必须遵守一定的规范且能够被互相理解。
• 安全性：加密用于给共享资源提供适当的保护，在网络上所有传递的敏感信息，都需要进行加密。拒绝服务攻击仍然是一个有待解决的问题。
• 可扩展性：系统要设计成随着业务量的增加，相应的系统也必须要能扩展来提供对应的服务。

根据上面的要求，在设计分布式系统时，应考虑以下几个问题：
系统如何拆分为子系统？
如何规划子系统间的通信？
通信过程中的安全如何考虑？
如何让子系统可以扩展？
子系统的可靠性如何保证？
数据的一致性是如何实现的？

比如，我们在设计通信时，我们可以采用面向消息的中间件，比如Apache ActiveMQ、RabbitMQ、Apache RocketMQ、Apache Kafka等，也有类似与 Google Protocol Buffer、Thrift等 RPC框架。
在设计分布式计算时，我们分布式计算可以采用 MapReduce、Apache Hadoop、Apache Spark 等。
在大数据和分布式存储方面，我们可以选择 Apache HBase、Apache Cassandra、Memcached、Redis、MongoDB等。
在分布式监控方面，常用的技术包括Nagios、Zabbix、Consul、ZooKeeper等。

用大白话聊聊分布式系统

分布式系统是怎么做内部工作节点协调的？

先从简单的情况入手，对于分布式计算（无状态）的情况，系统内部的协调需要做哪些工作：
1、怎么样找到服务？
在分布式系统内部，会有不同的服务（角色），服务 A 怎么找到服务 B 是需要解决的问题，一般来说服务注册与发现机制是常用的思路，所以可以了解一下服务注册发现机制实现原理，并且可以思考服务注册发现是选择做成 AP 还是 CP 系统更合理；
2、怎么样找到实例？
找到服务后，当前的请求应该选择发往服务的哪一个实例呢？一般来说，如果同一个服务的实例都是完全对等的（无状态），那么按负载均衡策略来处理就足够（轮询、权重、hash、一致性hash，fair等各种策略的适用场景）；如果同一个服务的实例不是对等的（有状态），那么需要通过路由服务（元数据服务等）先确定当前要访问的请求数据做哪一个实例上，然后再进行访问。
3、怎么样避免雪崩？
系统雪崩是指故障的由于正反馈循序导致不断扩大规则的故障。一次雪崩通常是由于整个系统中一个很小的部分出现故障于引发，进而导致系统其它部分也出现故障。比如系统中某一个服务的一个实例出现故障，导致负载均衡将该实例摘除而引起其它实例负载升高，最终导致该服务的所有实例像多米诺骨牌一样一个一个全部出现故障。避免雪崩总体的策略比较简单，只要是两个思路，一个是快速失败和降级机制（熔断、降级、限流等），通过快速减少系统负载来避免雪崩的发生；另一个为弹性扩容机制，通过快速增加系统的服务能力来避免雪崩的发生。这个根据不同的场景可以做不同的选择，或者两个策略都使用。一般来说，快速失败会导致部分的请求失败，如果分布式系统内部对一致性要求很高的话，快速失败会带来系统数据不一致的问题，弹性扩容会是一个比较好的选择，但是弹性扩容的实现成本和响应时间比快速失败要大得多。
4、怎么样监控告警？
对于一个分布式系统，如果我们不能很清楚地了解内部的状态，那么高可用是没有办法完全保障的，所以对分布式系统的监控（比如接口的时延和可用性等信息），分布式追踪 Trace，模拟故障的混沌工程，以及相关的告警等机制是一定要完善的；

接下来我们再来看分布式存储（有状态）的内部的协调是怎么做的，同时，前面介绍的分布式计算的协调方式在分布式存储中同样适用，就不再重复了：
1、CAP 及其相关理论与衡权：ACID、BASE 和 CAP 理论，了解这三个主题，推荐这一篇文章以及文章后面相关的参考文献：
英文版本：https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/，
中文版本：https://www.infoq.cn/article/cap-twelve-years-later-how-the-rules-have-changed/
2、怎么样做数据分片：单机的存储能力是不可能存储所有的数据的，所以需要解决怎么将数据按一定的规则分别存储到不同的机器上，目前使用比较多的方案为：Hash 和 Region 分片策略，可以了解一下它们的优缺点和各自的应用场景；
3、怎么样做数据复制：为了满足系统的高可用要求，需要对数据做冗余处理，目前的方案主要为：
中心化方案（主从复制、一致性协议比如 Raft 和 Paxos 等）和 去中心化的方案（Quorum 和 Vector Clock）
了解一下它们的优缺点和各自的应用场景，以及对系统外部表现出来的数据一致性级别（线性一致性、顺序一致性、最终一致性等）；
4、怎么样做分布式事务：对于分布式系统来说，要实现事务，首先需要一个对并发事务进行排序的能力，这样在事务冲突的时候，确认哪个事务提供成功，哪个事务提交失败。
对于单机系统来说这个完全不说问题，简单的通过时间戳加序号的方式就可以实现，但是对于分布式系统来说，系统中机器的时间不能完全同步，并且单台机器序号也没用全局意义，按上面的方式说不行的。
不过整个系统选一台机器按单机的模式生产事务ID是可以的，同城多中心和短距离的异地多中心都没有问题，不过想做成全球分布式系统的话，那么每一次事务都要去一个节点去获取事务ID的成本太高（比如中国杭州到美国东部的RTT为200+ms），Google 的 Spanner 是通过 GPS 和原子钟实现 TrueTime API 来解决这个问题从而实现全球分布式数据库的。
有了事务ID后，通过 2PC 或者 3PC 协议来实现分布式事务的原子性，其他部分和单机事务差别不大，就不再细说了。

如何系统性的学习分布式系统

中间件

中间件的定义与作用

为解决分布异构问题，人们提出了中间件的概念。
中间件是位于平台（硬件和操作系统）和应用之间的通用服务。【听起来有点像ROS【果然，ROS是中间件+工具链】】

---

如今的开发都采用的分布式架构，就是将一个系统拆分为若干份，比如一个淘宝app可能分为订单系统、用户系统、支付系统等等，订单系统可能采用Java开发、用户系统采用Go开发、支付系统采用Python开发，这些系统之间如何进行互联互通的呢？
一个项目从单体架构拆分成微服务架构要解决的第一个问题就是选择什么样的中间件技术来处理不同服务间的通讯问题，中间件为了解决通信的方式有很多种，比如RMI协议，典型的socket通信、dubbo采用的协议都遵循了RMI协议。
不仅如此，中间件还需具备高可用的功能，因为每个微服务往往都采用集群的方式部署，比如订单系统将数据通过中间件发送给支付系统，中间件就一定要保证数据的不丢失且高效送达。
此外，还需具备持久性，也就是数据可以存盘用于备份。这些都是中间件技术必须解决的问题。

中间件，向上不能够划归应用，往下又不能归入操作系统，于是就叫中间件了。但是把开发工具也称为中间件是不合适的，因为开发工具开发出来的软件，并不依赖开发工具与底层操作系统连接。

特点

中间件的特点可以概括为以下几点：
满足大量应用的需要
运行于多种硬件或OS平台
支持分布计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互
支持标准的协议
支持标准的接口

不管底层的计算机硬件和系统软件怎么更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件几乎不需要修改，从而保护了企业在应用软件开发和维护中的重大投资。【那设备树也是这个作用呀，不过设备树是将所有设备统一到某个主机，中间件是将所有主机统一到用户接口】

简单说：中间件有个很大的特点，是脱离于具体设计目标，而具备提供普遍独立功能需求的模块。这使得中间件一定是可替换的。如果一个系统设计中，中间件是不可替换的，要么这架构、框架设计有问题，要么就是这个中间件，在别处可能是个中间件，在这个系统内是引擎。

中间件的具体功能技术

中间件为了解决这些通信和平台这两大问题采用了很多协议/技术/方法论，如下所述：

RMI（Remote Method Invocations，远程调用）
Load Balancing（负载均衡，将访问负荷分散到各个服务器中）
Transparent Fail-over（透明的故障切换）
Clustering（集群用多个小的服务器代替大型机）
Back-end-Integration（后端集成，用现有的、新开发的系统如何去集成遗留的系统）
Transaction事务（全局/局部）全局事务（分布式事务）局部事务（在同一数据库联接内的事务）
Dynamic Redeployment（动态重新部署在不停止原系统的情况下，部署新的系统）
System Management（系统管理）
Threading（多线程处理）
Message-oriented Middleware（面向消息的中间件（异步的调用编程）
Component Life Cycle（组件的生命周期管理）
Resource pooling（资源池）
Security（安全）
Caching（缓存）