Web相关工具和框架

1、Dubbo

   Dubbo是阿里的一套高性能的分布式RPC框架，其拥有优秀的并发性能（但是大型文件的处理差）。

   比如有两个服务A和B，原来的话是A直接调用B的接口，现在则多出来一个注册中心，B向注册中心进行注册，A向注册中心订阅发现服务，这样A通过注册中心能够动态的获取B服务的相关信息，比如B服务是部署在多台机子上的，则A会收到服务地址列表，然后选择一个机子去调用B服务的接口，B服务中有一台机子下线的话，注册中心会将其从服务地址列表删除。

    如下所示，我们的服务首先向Dubbo的注册中心进行注册（发送服务的IP、端口、接口方法），消费者向注册中心订阅服务（发送所求的服务信息）以发现服务，注册中心根据消费者所求服务信息匹配对应的提供者列表给消费者，然后消费者从服务提供者地址列表中，基于软负载均衡算法选一台服务提供者进行调用。当有新的远程调用方法注册到注册中心时, 注册中心会通知消费者。注册中心始终不代替调用者发送请求到服务提供者，它只是告诉调用者服务方地址，调用方根据具体地址请求服务，这样，调用者无需知道服务的ip和端口号, 只需要服务名称就可以调用到服务提供者的方法，服务提供方可以平滑增加或减少机器。

  

   服务提供者provider实际上运行在Dubbo的Container中，即Container是服务运行容器，负责启动、加载和运行服务提供者。消费者和服务者还会定时将服务调用次数、时间等信息发送给监控中心Monitor用于监控，如下所示：

    Dubbo是一个分布式服务框架，SpringCloud是一个分布式的整体解决方案，Dubbo服务的调用方式是RPC，SpringCloud是REST API。Dubbo底层基于TCP协议，默认使用自己的dubbo协议来进行通信，配合以Hession序列化完成RPC通信。SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会使用更大的报文，占用带宽多，但REST相比RPC更为灵活。 

2、RPC

 RPC（Remote Procedure Call），即远程过程调用，简单的理解就是一个节点请求另一个节点提供的服务。从通信协议的层面，大致可以分为：

       1）基于HTTP协议的（基于文本的SOAP（XML）、REST（JSON），基于二进制Hessian（Binary））；
       2）基于TCP协议的（通常会借助Netty、Mina等高性能网络框架）

 3、Nacos

   Nacos是阿里巴巴开源的服务注册中心以及配置中心，Dubbo使用Nacos来实现服务的注册中心（dubbo是rpc框架，负责服务间的调用，nacos用来实现服务注册和治理），其它如Zookeeper（Dubbo原来使用Zookeeper，现在改成了Nacos）、Eureka也可以用来实现服务的注册与发现。

     Dubbo：A服务能提供3种服务功能（接口），B服务能提供4种服务功能，C服务能提供5种服务功能，A服务也许需要使用B服务的功能，B服务需要使用C服务的功能，那让我们组合一波服务搞点事情吧。

     Nacos：你们的信息都来我这注册一下，由我负责管理，方便别的服务来获取。

4、Eureka

  Eureka类似Nacos，也是用来实现服务注册与发现，它是Spring Cloud默认的也是推荐的服务注册中心。

   Nacos比Eureka更新，但Eureka使用者多，考虑项目的稳定性的话可以选择Eureka，考虑长期发展的话可以选择Nacos。

5、CAP & BASE

1）、CAP

  CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。

   

• 一致性 ：数据在多个节点之间能够保持一致。
• 可用性：服务一直处于可用的状态，每次请求都能获得正确的响应。
• 分区容错性：分布式系统在遇到任何分区故障的时候，仍然能够对外提供服务。

    对于分布式系统来说，是避免不了分区的，所以分区容错性是一定要满足的，那么在满足分区容错的基础上，能不能同时满足一致性和可用性？比如现在有两个分区N1和N2，N1和N2分别有不同的服务S1和S2，以及不同的分区存储D1和D2。用户访问了N1，修改了D1的数据后立即又有用户再次访问，请求落在了N2，此时D1和D2的数据不一致。

• 要保证数据一致性的话，第二次访问的时候要等待N1分区修改的数据同步到N2上，而同步的时间是无法保证的，即同步时间无限延长，无法保证可用性。
• 要保证可用性的话，第二次访问的时候就立即返回数据，但是此时响应的数据和D1不一致，一致性无法保证。

   由上面可得出，CAP三者不可同得，对于分布式系统，分区是客观存在的，必须保证P，所以只能是选择CP without A或者AP wihtout C。CP即每个写请求都需要在分区之间强一致来保证数据一致性，但这会导致同步时间无限延长，很多传统的数据库分布式事务都属于这种模式。AP即为了高可用，每个节点只使用本地数据提供服务，而这样会导致全局数据的不一致性，现在众多的NoSQL都属于此类。

   对于微服务中作为注册中心的组件的话，ZooKeeper是 CP架构，比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。Eureka则是 AP架构，Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。Nacos 不仅支持 CP 也支持 AP。

2）、BASE

   BASE 是指BA（Basically Available基本可用）、S（Soft-state软状态）、E（Eventually Consistent最终一致性）。

   BA基本可用：出现故障的时候，允许损失部分可用性，即保证核心可用。比如电商大促时，为了应对访问量激增以保证购物系统的稳定性，部分用户可能会被引导到降级页面，这属于功能损失。再比如，正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒返回结果，这属于响应时间上的损失。

   软状态：指允许系统在不同节点的数据副本之间进行数据同步的过程存在延时，软状态不能违背“基本可用”的要求。软状态相当于是“弱一致性”，即不一定能读到最新的值，也不能保证在一定时间后读取到的数据是最新的，只会尽量在某个时刻达到数据一致的状态。

   最终一致性：系统中所有节点的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。相当于是弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

   一般常用的是最终一致性，但是也有一些对一致性要求比较高的，比如银行的交易系统，这种要保证强一致性。

6、Web service

   Web service是提供给外部使用的，通过Web调用的一组API，它是一种跨语言和跨平台的远程调用技术。比如提供天气查询的Web service，使用java或php等都能够对其进行调用。Web service其实是一种架构规范，所以可以在任何支持这些标准规范的环境（Windows,Linux）中使用。

   WebService的理念是专业的事情交给专业的人去做，比如我们的服务中需要获取天气信息、保存照片等功能，那么可以使用提供天气预报的WebService来获取天气，使用提供相册功能的WebService来保存照片，而不用自己来一一实现这些功能。

   webService有三要素：SOAP、WSDL、UDDI，如下所示，客户端通过 UDDI 注册表（注册中心）查找服务，UDDI 指向 WSDL （描述服务端的服务信息），户端和服务端通过 SOAP 消息（基于HTTP的XML数据格式）交换信息。可以看到，WebService符合 Web 服务体系架构：客户端-注册中心-服务端。

     目前Web service除了使用SOAP以外，还增加了更简洁的Restful架构，在数据格式上也增加了json等轻量级格式的使用。

    考虑性能时不建议使用WebService。

7、Docker

   对于一些软件，比如IE，如果我们想安装新老版本到同一台电脑上进行测试的话是不行的，只能安装虚拟机，一个版本的IE对应一个虚拟机。还有就是有可能两个软件之间有冲突，比如360和腾讯管家，它们不能同时安装到一台电脑上，只能使用虚拟机来隔离两个软件。再比如，我们在测试环境Ubuntu上安装的软件，其在正式环境centos上不支持该软件，只能使用虚拟机了。

   上面这些问题，除了使用虚拟机解决外，还可以使用Docker。Docker可以实现类似虚拟机隔离应用环境的功能，并且开销比虚拟机小，它就是一种轻量级、进程级的VM。Docker并不会运行一个独立的操作系统，而是提供一个“运行环境”来运行应用，这个“运行环境”里包含操作系统库、运行库、第三方库等来为应用服务。多个“运行环境”就提供了多个互隔离的用户空间，让应用进程之间不会相互影响，这些相互隔离的用户空间就像一个大盒子里面装着各种零件（应用）一样，这种技术就叫容器技术。容器（Container）给应用进程提供了一个“运行环境”，使进程运行得就好像在一个独立的操作系统上。

    相比虚拟机，Docker这样的容器技术属于轻量级的虚拟化，启动时间很快，几秒钟就能完成，而且，它对资源的利用率很高，一台主机可以同时运行几千个Docker容器。此外，Docker占的空间很小，虚拟机一般要几GB到几十GB的空间，而Docker容器只需要MB级甚至KB级。容器化技术具有可移植性，其不依赖具体的操作系统或云平台，比如在阿里云或腾讯云直接随意迁移。

   在开发的时候，经常需要安装MySQL、Redis、Kafka，以及Kafka依赖的ZooKeeper等服务，使用Docker Desktop来安装运行这些服务的话会很方便，比如我们使用一条Docker命令就能下载和安装MySQL。

  在运行Docker容器前需要编写Docker File，通过 Docker File 生成指定的镜像，然后才能运行 Docker 容器。我们在自己的电脑、测试环境电脑以及正式环境电脑上使用相同的Docker File就能生成相同的镜像（相同的操作系统、第三方软件支持等），这样就能避免操作系统不同、运行环境不同等带来的问题。一般情况下都不需要从头开始编写 Docker File，在 Docker Hub 中有来自世界各地的工程师编写好的镜像，你可以基于此修改。如下所示，我们使用Docker来打包和发布应用会很方便：

  如下所示，我们在build目录下编写一个docker-compose.yml文件来定义我们要运行的所有服务，在该文件中，我们定义了MySQL、Redis、Kafka以及Kafka依赖的ZooKeeper服务，各服务均暴露标准端口，且MySQL的root口令设置为password，第一次启动MySQL时，使用sql / schema.sql文件初始化数据库表结构。所有数据盘均挂载到build目录下的docker目录。

version: "3"
services:
  zookeeper:
    image: bitnami/zookeeper:3.5
    container_name: zookeeper
    ports:
      - "2181:2181"
    environment:
      - ALLOW_ANONYMOUS_LOGIN=yes
    volumes:
      - "./docker/zookeeper-data:/bitnami"

  kafka:
    image: bitnami/kafka:3.0
    container_name: kafka
    ports:
      - "9092:9092"
    depends_on:
      - zookeeper
    environment:
      - KAFKA_BROKER_ID=1
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://127.0.0.1:9092
      - KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
      - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true
      - ALLOW_PLAINTEXT_LISTENER=yes
    volumes:
      - "./docker/kafka-data:/bitnami"

  redis:
    image: redis:6.2
    container_name: redis
    ports:
      - "6379:6379"
    volumes:
      - "./docker/redis-data:/data"

  mysql:
    image: mysql:8
    container_name: mysql
    ports:
      - "3306:3306"
    command: --default-authentication-plugin=mysql_native_password
    environment:
      - MYSQL_ROOT_PASSWORD=password
    volumes:
      - "./sql/schema.sql:/docker-entrypoint-initdb.d/1-schema.sql:ro"
      - "./docker/mysql-data:/var/lib/mysql"

   

   以后随着业务规模逐渐扩大，容器越来越多，可以使用kubernets（俗称k8s）来协调和调度这些容器，保障升级应用程序时不会中断服务，以及监视应用的运行情况、故障处理、批量重启应用、负载均衡等。Docker 是一个容器化平台，而 k8s 是 Docker 等容器平台的协调器，k8s又称为容器的编排管理工具，它可以使我们应用的部署和运维更加方便，其它类似的还有Docker Swarm。

8、Kubernets

  当我们使用的Docker容器越来越多的时候，可能就需要使用K8S（Kubernets）来管理这些容器。K8S可以实现以下功能：容器挂掉后，使用K8S来自动重启容器；协调容器之间的通信；编排容器，使它们按照一定的顺序和逻辑运行；监控容器的CPU等使用情况；监视容器内应用的运行情况；不中断应用服务来升级应用程序。