为什么需要rpc，为什么需要spring boot，微服务是什么，分布式是什么，redis集群，docker技术，zookeeper技术

传统的软件架构是单体开发，这种虽然易维护、测试和部署，但这种服务的耦合度极高，也容易出现出现单点故障。同时，随着业务量和访问量的增加，也容易出现性能瓶颈和并发问题。

基于单体架构带来的困扰，为了解耦合，为了避免单点故障，且能快速开发，将各个服务拆分，部署在不同的服务器或Tomcat上，各个服务之间相互调用，如图所示：

我们如果用spring mvc框架，他虽然开发成本低，但配置成本高，因而，有没有一个框架代替spring MVC。因而，spring boot便应运而生，其拆箱可用。Spring boot 通过stater集成各种插件，大量的自动化配置，比如spring-boot-starter-web引入了spring MVC，spring-boot-starter-data-redis引入Redis，简化了spring MVC中的很多配置。同时，服务可拆分，方便部署在多个Tomcat或多个服务器，但各个服务之间的如何通信？这就需要网络传输。

网络传输有四层协议，应用层，传输层，网络层，链路层。使用以用层协议为主的HTTP通信，但HTTP协议包含太多无用的信息，包括请求头和请求空行。而真正需要的用户数据只在请求体或者路由之后，在高可用的现代化软件开发体系中，显然太多的无用的字段会影响网络传输的。因而，能不能直接以传输层协议为主，进行服务间的通信？

因而，我们就想到了传输层的TCP协议，通过序列化将对象写出jvm，反序列化将对象写入jvm，这样重新引入新的服务协议，即rpc协议【remote procedure caller 远程服务调用】。这样，就规避了http协议带来的无效协议信息。支持rpc框架的有netty，dubbo等。Netty底层使用的是nio，dubbo底层使用的netty，性能还是比较高的。

各个服务相对独立，又相互联系，便组成了微服务，也能避免单点故障。架构微服务便有一个新的名词，分布式架构。分布式架构比单体架构更复杂的，但更好的实现高内聚和低耦合。

由于服务之间相对独立，那么怎么样可以共享sesstion？复制算法比较耗时，如果存储到非关系型数据库中，但数据存储到磁盘上的，随着数据量的增加，从数据库中读取数据耗性能，能不能直接在内存中操作，因为就出现了非关系型数据库：Redis。

Redis纯内存操作，且是单线程框架，避免了多线程的上下文切换；它同时采用NIO的多路复用技术，可以避免bio那种连接阻塞和读写阻塞，这就让Redis有很高的性能。Redis可以用做缓存，限流，分布式事务，计数器，投票，点赞，共同好友，相似好友，存储session会话等等。

如果访问量很大，单台Redis的并发毕竟有限，同时单台redis也会存在单点故障，这就需要多台redis集群，master redis 和 slave redis。master redis 需要时刻将数据写入到slave redis中，以免当前master redis 挂了，必须在保证数据安全的情况下，快速从slave redis选举出master redis。谁来监听master redis的生命状态，如果master redis挂了，谁能监听到并重新快速选举出新的master redis。因而，需要Sentinel集群选举Leader，兵谏亭redis的生命状态。但是，谁来监听Sentinel集群，这就需要分布式协调组件zookeeper。

如果没有做redis集群，但redis挂了，怎么办？这就需要redis数据备份，可以使用rdb或aof实现将redis写入到磁盘，并在redis启动后，将数据恢复到redis中。

Session共享解决了，但是如何实现各个服务的负载，比如动态将用户的请求转发到哪台服务器上？这可以使用Ngin。Nginx使用的进程级别的通信，性能有一两拨千金的作用。它由三种算法进行负载，轮询、加权，hash算法，可以受用select、poll、epoll进行NIO多路复用。如果访问量很大，单台Nginx的并发毕竟有限，因而，需要多台Nginx集群。如何监听Nginx集群的心跳，以及主从Nginx的选举等，这里可以使用keepalive集群，如何监听keepAlive集群，这就需要分布式协调组件zookeeper。

zookeeper采用事件监听、有序节点临时节点的特性，来选举出master和slave的集群，节点大的监听节点小的，如图所示：

假设现在有十台服务器，每台服务器上均部署web应用，因而，每台服务器上都需要部署Tomcat和jdk，假如使用手动的方式去部署Tomcat和jdk，需要经过以下步骤：

• jdk
  • 下载jdk
  • 安装jdk
  • 配置环境变量和系统变量
  • 。。。
• Tomcat
  • 下载Tomcat
  • 配置Tomcat
    • 修改Tomcat的日志编码格式
    • 设置post请求的数据编码格式
    • 。。。

这些配置加起来非常繁琐，配置Tomcat和下载jdk要受到操作系统的影响，操作起来非常的不方便，况且要配置十台这样的服务器，但凡有一台疏忽大意，都有可能配置错误。这只是Tomcat和jdk的配置，nginx，mysql，keepalive等还没有配置，加起来会更麻烦和容易出错。

此外，开发还分为测试环境和正式环境，往往在测试环境是正常的，但在测试环境是不正常，这就造成了环境的不一致。

因而，就在考虑在多台服务器中的配置，能不能以一个镜像的形式，打包安装到每个服务器上，因而，这就出现了如今很火的docker技术，如图所示：

涉及到的各个技术的细节，并没有涉及太深，只是展示微服务和分布式的由来。