2019/06/26日知识总结

1、微服务架构思想

https://www.cnblogs.com/aspirant/p/9089146.html

2、HTTP状态信息

3、Zookeeper相关

https://www.cnblogs.com/aspirant/p/9088322.html

Zookeeper是可以集群复制的，集群间通过Zookeeper Atomic Broadcast协议来保持数据的一致性；

该协议包括两个阶段：leader election阶段和Atomic broadcast阶段。集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过broadcast将所有的更新告诉follower。当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leader election的过程就结束了，将进入Atomic broadcast的过程。Actomic broadcast同步leader和follower之间的信息，保证leader和follower具备相同的系统状态。

路由和负载均衡的实现

　　当服务越来越多，规模越来越大时，对应的机器数量也越来越庞大，单靠人工来管理和维护服务及地址的配置信息，已经越来越困难。并且，依赖单一的硬件负载均衡设备或者使用LVS、Nginx等软件方案进行路由和负载均衡调度，单点故障的问题也开始凸显，一旦服务路由或者负载均衡服务器宕机，依赖其的所有服务均将失效。如果采用双机高可用的部署方案，使用一台服务器“stand by”，能部分解决问题，但是鉴于负载均衡设备的昂贵成本，已难以全面推广。

　　一旦服务器与ZooKeeper集群断开连接，节点也就不存在了，通过注册相应的watcher，服务消费者能够第一时间获知服务提供者机器信息的变更。利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。Zookeeper集群间通过Zab协议，服务配置信息能够保持一致，而Zookeeper本身容错特性和leader选举机制，能保证我们方便地进行扩容。

　　Zookeeper中，服务提供者在启动时，将其提供的服务名称、服务器地址、以节点的形式注册到服务配置中心，服务消费者通过服务配置中心来获得需要调用的服务名称节点下的机器列表节点。通过前面所介绍的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，由于znode非持久的特性，相应的机器可以动态地从服务配置中心里面移除，并触发服务消费者的watcher。在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询到的服务信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求到服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更(机器上线或者下线)，变更行为会触发服务消费者注册的相应的watcher进行服务地址的重新查询。这种无中心化的结构，使得服务消费者在服务信息没有变更时，几乎不依赖配置中心，解决了之前负载均衡设备所导致的单点故障的问题，并且大大降低了服务配置中心的压力。

 　　通过Zookeeper来实现服务动态注册、机器上线与下线的动态感知，扩容方便，容错性好，且无中心化结构能够解决之前使用负载均衡设备所带来的单点故障问题。只有当配置信息更新时服务消费者才会去Zookeeper上获取最新的服务地址列表，其他时候使用本地缓存即可，这样服务消费者在服务信息没有变更时，几乎不依赖配置中心，能大大降低配置中心的压力。

 

http://developer.51cto.com/art/201809/583184.htm

https://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/index.html

4、Docker

https://blog.csdn.net/gerryke/article/details/80485136

https://www.csdn.net/article/2014-07-02/2820497-what

5、中转机

 

6、环境部署

步骤一：参数化构建：设置参数branch，其默认值为origin/release/${version}；version字段值为版本号，如：V2.1；svnVersion及svnDir；

步骤二：源码管理：从GIT拉取源代码，拉取的分支为branch的值；

步骤三：构建触发器轮询SCM；

步骤四：在构建环境中设置Inject environment variables to the build process的Properties Content中设置构建脚本中使用的变量；

步骤五：构建：第一步低缓配置文件中的数据信息，如disconf文件、dubbo.properties文件中的数据，第二不调用顶层Maven目标构建：版本选择maven-linux，目标是clean package -U -Dmaven.test.skip=true；第三部执行shell将构建后的数据包放到执行目录；

步骤六：构建后操作，将构建后的zip包上传到指定中转机特定目录下，执行syncfile.sh和restart.sh命令；上述命令中前者判断包是否存在且唯一、并生成MD5值及将数据包同步到其他中转机节点，后者主要实现登录丰箱、调接口发布具体应用到服务节点。 

7、丰箱环境使用

当前丰箱使用支持微服务和Jetty两种；

微服务的zip包放在apps目录下；

登录中转机确定存放目录为cd /app/appsystem/{应用名-dcn}，如cd /app/appsystem/demo-dcn；然后查看下面的文件为apps、env和script文件，zip包就放在apps目录下，生成md5.txt，并从中转机A同步到中转机B中；

手动同步方式：cd apps目录，执行脚本sh app/appsystem/synvfile.sh {应用名} ；而后重启容器；重启容器的步骤为：容器销毁、容器启动、加载基础配置、从文件服务器中下载zip文件、zip文件解压到/app/deploy/目录、执行start_app.sh脚本；

Jetty的需要创建目录：

登录中转机，确定应用存放目录cd /app/appsystem/{jetty 应用名-dcn}，如cd /app/appsystem/demo-jetty-dcn;

进入apps目录，创建{resources和webapps目录}，进入webapps目录，上传对应的.war包；例如：

$cd /apps

$mkdir -p webapps && mkdir -p resources

$cd /apps

$cd webapps

$上传war包

$cp /app/appsystem/jetty-tmp.xml ./demo-jetty.xml拷贝xml模板，将里面的{*.war}替换成自己的war；

执行同步脚本：$ sh /app/appsystem/syncfile-jetty.sh demo-jetty，并重启丰箱；