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