http请求应该首先打在堡垒主机的Nginx(运行docker拉取的镜像，应该还需要运行某些脚本配置与生产环境对应)上然后基于某种随机轮询或客户端地址hash的方式请求落在springboot内置的tomcat上面(在这个过程中优先执行过滤器的一些操作)，提供该web服务应该是运行的jar或者war包.web服务将注入eureka注册中心提供的来自各分布式节点提供的微服务。如果是dubbo则使用zk注册中心提供的来自各分布式节点提供的微服务。控制层一般作为服务消费者调用注册中心的服务，响应页面过来的请求，服务提供者一般是连接了数据库的jar包。
前后端数据交互使用http请求做json数据交互基本足够了，一些文档流类型的传输可以使用mongodb提供副本集群上传下载文档流的服务。做分布式缓存使用redis提供相应的服务(是否需要使用集群模式？分布式大牛与redis设计者何去何从)。分布式事务可以设计并使用本地消息表或者使用消息中间件。运维人员使用docker拉取中间件镜像并运行以提供相应的套接字访问方式，代码开发人员使用spring整合中间件都是一贯的料性。
微服务读取套接字地址使用springcould的配置中心或者zk提供的配置文件读取方式均可。配置文件和源码应该在git库分别创建不同的文件夹用于分离。git库的代码会被jekins或者大牛写好的python脚本(借用maven和gradle命令以及远程拷贝功能基本可以实现)构建各个模块对应的微服务jar包用于服务发布。springcould的配置中心需要提供有消息中间件的套接字访问方式。如果使用docker运行rabbitmq镜像提供rabbitmq的消息服务就不需要关注erlong的安装。对于持久化的mysql数据库我不清楚是否需要使用docker运行这样的容器，因为mysql镜像作为容器运行会丢失数据。而数据卷的学习需要花费一定的精力。花费更多精力的应该是docker提供中间件集群服务，虽然有直接的集群镜像，但如果不清楚经典的集群配置方式后续会带来一大堆问题。配置集群模式至少应该打通各节点间的免密登录ssh
用户及其权限模块单点登录使用redis？
流程审核模块使用activiti工作流？
线程异步处理使用quartz？
以前我认为使用spring整合中间件并掌握中间件的常用api就已经把spring玩的一溜一溜的，后来我发现手动扫包
并对包下的接口生成动态代理对象注入spring容器并为容器中不同的代理对象注入属性才能获得一些成就感。
基于多份数据带来的思考，数据备份往往消耗网络带宽，并在这备份的过程中，如果要保证主从一致，那么就必须保证从节点成功处理主节点下发的任务并告知主节点，主节点才算成功，主节点漫长等待从节点的回应能增加数据的安全性却让用户感到不耐烦，通常的做法是记个日志然后从节点异步处理，这时候如果异步到从节点失败，那么主从数据就会不一致。zk 使用paxos算法可以保证强一致。一些普通的选举算法并不附带强一致功能，而是通过一些网络流畅度的因素选举出主节点。
有新想法再更新。。。
原文：https://blog.51cto.com/12165865/2435716