作为一个程序员，学习任何技术，最重要的是形成该技术的知识体系，这样才能够学以致用，后续遇到相似的需求或者问题可以快速从该知识体系中获取对应的解决方案。只有形成了知识体系，后续才可以对该知识体系就绪修订总结，一遍又一遍~，不然你会发现自身学习的技术非常的散乱，没有条理性，今天学redis，明天学vue，后天学大数据，搞不懂学这些的意义是啥，就好像看到别人在学自己就去学，然后学了又不用，过段时间又忘记了，可见形成知识体系多重要，让技术的学习有理可循。
因此，从今天开始，了解以及实战该知识体系中遇到的各种技术问题和前因后果，拓宽和完整自身的技术水平。
路漫漫而修远兮，吾将上下而求索。
1、大型分布式网站
1.1、特点
用户多，更新频繁，海量数据
1.2、目标
高性能、高可用、可伸缩、安全性、可扩展、敏捷性
1.3、架构模式
分层、分割、分布式、集群、缓存、异步、冗余、安全、自动化、敏捷性
上面大概介绍了一下当前大型分布式大一些特点，以及目标和架构模式，但是想要完全的掌握大型分布式网站的架构模式以及对工作中遇到的各种技术问题可以快速准确的提供方案选型，还是得自己搞懂大型分布式网站是怎么演进而来的，毕竟不是开发任何项目，一上来就分布式，微服务，集群，缓存，容器部署，k8s的，还要考虑人力成本和服务器成本以及上线时间各种因素，作为一个技术负责人，最起码的要求就是能够在当前资源条件下，提供一个最合适的技术架构。
技术什么的，作为程序员，随便看看官方文档或者相关教程就可以掌握了，毕竟咱又不是博士研究生，专门攻克技术难题的，我们要做的是在当前技术栈的情况下，能够整合出一套最适合的技术选型来实现业务需求，为业务发展带来有效的支撑。毕竟几乎很大一部分程序员做的都是业务，没有业务需求就没有钱，没有钱哪有机会去研究更加先进的技术。
所以，下面让我们开始吧，从单体架构到分布式架构，探寻一下这个演进过程中遇到的问题以及解决方案。
2、架构的演进之路
这里会对每一次演进进行实战，以及对演进过程中遇到的技术进行学习和使用，比如遇到Redis，会有链接链接到Redis进行Redis的学习，部署和研究。
2.1、环境准备
2.1.1、Window安装IDEA
2.1.2、Linux服务器准备
安装VMware15
CentOS7镜像官网下载
VMWare安装CentOS7超全图解
最小系统Centos7进行网络配置以及 ifconfig和vim的安装
VMWare 克隆Linux虚拟机
2.1.4、Window JDK环境准备
2.2.5、Maven环境准备
略
2.2.6、gitee环境准备
略
2.2、初始架构:单机架构
2.2.1、架构图
2.2.2、架构描述
1、用户在浏览器输入网址
2、浏览器从DNS服务器根据域名获取实际IP地址
3、浏览器根据IP地址去Tomcat应用服务器获取资源
4、Tomcat应用服务器从数据库获取资源
5、返回到浏览器进行渲染
在这个架构中，我们的web应用和数据库是放在一个服务的，实现起来简单方便，只需要找台服务器安装好即可，维护也简单，但是也要考虑做备份等。
2.2.3、实战
暂无
2.2.4、所用技术
2.2.4.1、Web容器
正常在这个阶段，如果是Java的话，我们可以选用Tomcat、Jetty、Undertow，Weblogic，Jboss，后面我们最经常使用的是Tomcat，Undertow，可以内嵌在springboot中使用。
2.2.4.2、数据库
数据库通常选择的是MySQL，后面MySQL被Oracle收购后慢慢就不开源了，然后大家可以选择MariaDB，国企也可以选择PostgreSQL，PostgreSQL 是一个免费的对象-关系数据库服务器(ORDBMS)，在灵活的BSD许可证下发行。
2.2.5、架构模式
这里目前只用了分层这一架构模式，我们开发的应用服务器肯定是要分为应用层，服务层，数据层来进行开发的，比如springboot开发的web应用，正常都分controller、service、dao层，controller层获取前端传递过来的参数和返回数据，service进行业务逻辑处理，dao层进行数据库操作。
2.2.6、面临的问题
随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务，我们需要对该架构进行优化。
2.3、第一次演进:Tomcat和数据库独立部署
2.3.1、架构图
2.3.2、架构描述
Tomcat和数据库独立部署后，二者不会互相抢占资源，又可以支撑更大的用户访问啦。相比刚开始的架构，成本投入也稍微多了点，毕竟新增了一台服务器，话说我们的个人博客一般都是一台服务器搞定，也就是最初始的架构，毕竟个人博客也不会有多少人访问。
2.3.3、实战
暂无
2.3.4、所用技术
2.3.4.1、Web容器
跟初始架构一致
2.3.4.2、数据库
跟初始架构一致
2.3.5、架构模式
跟初始架构一致
2.3.6、面临的问题
随着用户数的增长，如果所有数据都打到数据库的话，数据库的并发读写将会面临严重问题，那么我们有需要对架构进行优化。
2.4、第二次演进:引入缓存
2.4.1、架构图
2.4.2、架构描述
该架构引入了本地缓存和分布式缓存，那么一个请求进来后查询资源逻辑会变成如下逻辑
1、从本地缓存获取
2、本地缓存没有从分布式缓存获取
3、分布式缓存没有再从数据库获取
因此极大的缓解了数据库的压力，当然我们课先只引用本地缓存或者只引用分布式缓存也可以，毕竟加了缓存后续要考虑缓存一致性问题，缓存雪崩，缓存击穿等，增加了技术复杂度。
2.4.3、实战
暂无
2.4.4、所用技术
引入缓存后就需要考虑缓存一致性，缓存的伸缩性，持久化方案，所以进行技术选型的是后一定要注意。
2.4.4.1、本地缓存
目前比较流行的本地缓存实现有：Ehcache、GuavaCache、Caffeine等，各有各的优缺点，作为架构师，必须要懂得每一个的优缺点，好选用最好的一个。
2.4.4.2、分布式缓存
分布式缓存一般使用的是Redis，当然还有Memcached，我们需要了解二者之间的优缺点。
2.4.5、架构模式
缓存
2.4.6、面临的问题
随着用户的增长，并发压力就落到了Tomcat上面，毕竟单台服务器Tomcat不一定扛得住并发量，那么需要继续对架构进行优化。
2.5、第三次演进:引入反向代理实现负载均衡
2.5.1、架构图
2.5.2、架构描述
1、从DNS获取的是nginx反向代理的IP地址
2、请求到达nginx后从配置的多个应用服务器的地址中按负载方案选择一个应用服务器
上面的架构是基于之前的架构演变过来的，也就是也会有本地缓存，只不过没有画出来，分布式缓存和数据库是所用应用公用的，因此画在了一起，这里面每台Tomcat是一模一样的，可以横向扩展，现在请求压力已经分到多台Tomcat上了，所以性能肯定有很大的提升。毕竟还可以横向扩展的说，不过这种架构引入了nginx后，当然会面临新的问题，比如session的问题。
每一次架构的优化，解决了一部分问题，但是也会产生一些问题，我们要做的就是对这些进行取舍。比如session问题我们可以进行ip绑定，也可以进行无状态登录改造，当然进行无状态登录改造又会面临新的问题，无穷无尽，没有完美的技术。
2.5.3、实战
暂无
2.5.4、所用技术
2.5.4.1、反向代理
反向代理我们可以选择Nginx，也还有类似HAproxy等，每种反向代理的使用和配置都不一样，需要后面好好研究。
2.5.5、架构模式
集群
2.5.6、面临的问题
反向代理使得应用服务器可支持的并发量大大增加了，但是并发量的增加，最后压力都给到了单机的数据库中，毕竟有很多数据和业务逻辑操作是必须到数据库的，而不是靠缓存就可以解决的，比如下单，比如关注点赞收藏等，既然单机数据库已经成为了瓶颈，那么我们必须继续对架构进行优化。
2.6、第四次演进:数据库读写分离
2.6.1、架构图
2.6.2、架构描述
增加了数据库读写分离后，我们可以有一个写库多个读库，数据写入写库后，同步到读库中。但是从写库同步到读库是后台线程异步的，所以会有时间差，刚写入的数据读库中不一定有，如果某些数据比较考虑实时性，可以同步写一份到分布式缓存中，这样读取就可以直接从缓存中获取，我们可以用Mycat数据库中间件来屏蔽客户端的访问细节，通过它来访问下层数据库。当然这种架构会映入数据同步，数据一致性的问题。
2.6.3、实战
暂无
2.6.4、所用技术
2.6.4.1、读写分离中间件
Mycat,ShardingSphere,Apache ShardingSphere 是一款分布式的数据库生态系统，它包含两大产品：ShardingSphere-Proxy,ShardingSphere-JDBC，对于这些中间件，我们必须了解它的使用和原理以及优缺点，当然还有数据库写库读库的同步技术以及要注意的问题。
2.6.5、架构模式
这里用了读写分离，应该是用了冗余的架构模式，毕竟数据变成两份了，不过容易还可以提高可用性和安全性，毕竟如果写库挂了，读库还是可以正常使用的。
2.6.6、面临的问题
这种情况下，做好备份，几乎可以抗住很大的用户量了，但是加入你们网站的业务越来越多，比如论坛，直播，短视频等都做，而这些业务之间的访问区别是巨大的，如果只有一个数据库，那么会互相抢占资源，因此如果遇到这总业务场景,我们需要按业务进行分库。
2.7、第五次演进:数据库按业务分库
2.7.1、架构图
2.7.2、架构描述
我们数据库按业务分库了后，不同的业务之间就不会有数据库资源的竞争了，但是按业务分库后也会有分库后面临的新问题，比如如果两个业务之间有分布式事务问题，还有两个业务之间会有多表联合查询问题，这些问题需要有新的方案来解决，后续得好好研究。
2.7.3、实战
暂无
2.7.4、所用技术
数据库分库，集群，主从复制，多数据源等。
2.7.5、架构模式
分库
2.7.6、面临的问题
如果此时用户量继续增大，那么我们的单机写库会逐渐达到性能瓶颈，所以需要继续进行优化。
2.8、第六次演进:大表拆分为小表
2.8.1、架构图
2.8.2、架构描述
1、假设user表数据量太大了，那么单表性能会有问题，我们可以按用户注册时间或者用户ID进行hash,分到不同的表中
2、我们还可以把不同表分到不同的数据库中，这样相当于完全可以对写表进行横向扩展，数据库将不再是瓶颈，到这种层度，已近类似于一个分布式的数据库了，相应的运维难度也会增加，并且开发上的难度也会增加
3、这种情况下，表可以无限向下拆分，比如按年，按月，按天，按小时等，拆分后的表也可放在不同的库中，完全横向扩展。
2.8.3、实战
暂无
2.8.4、所用技术
数据库分表分库，集群，联合查询等
2.8.5、架构模式
分表
2.8.6、面临的问题
此时我们的数据库和Tomcat都是可以横向扩展的，然后分布式缓存也是可以横向扩展的，可支持的并发量有了大幅度的提高，如果用户量继续变大，最终我们单机的反向代理Nginx将会成为性能瓶颈，所以要继续优化。
2.9、第七次演进：使用LVS或F5来使多个Nginx负载均衡
2.9.1、架构图
2.9.2、架构描述
由于瓶颈在Nginx，因此无法通过两层的Nginx来实现多个Nginx的负载均衡。图中的LVS和F5是工作在网络第四层的负载均衡解决方案，其中LVS是软件，运行在操作系统内核态，可对TCP请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于Nginx，可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件，与LVS提供的能力类似，性能比LVS更高，但价格昂贵。由于LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚拟IP重定向到另外一台正常的LVS服务器，从而达到LVS服务器高可用的效果。
此处需要注意的是，上图中从Nginx层到Tomcat层这样画并不代表全部Nginx都转发请求到全部的Tomcat，在实际使用时，可能会是几个Nginx下面接一部分的Tomcat，这些Nginx之间通过keepalived实现高可用，其他的Nginx接另外的Tomcat，这样可接入的Tomcat数量就能成倍的增加。
2.9.3、实战
暂无
2.9.4、所用技术
LVS，F5，keepalive
2.9.5、架构模式
集群，负载均衡
2.9.6、面临的问题
由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同
2.10、第八次演进:通过DNS轮询实现机房间的负载均衡
2.10.1、架构图
2.10.2、架构描述
在DNS服务器配置一个域名对应多个IP地址，每个IP地址对应到不同机房里的虚拟IP。当用户访问www.suibibk.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可以做到机房级别的水平扩展，千万级到亿级的并发量都可以通过增加机房来解决，系统入口处的请求并发量不再是问题了。用户的增长也不再是压力。
2.10.3、实战
暂无
2.10.4、所用技术
DNS轮训
2.10.5、架构模式
集群，负载均衡
2.10.6、面临的问题
到这一步，用户的访问量上升已经不再是问题，但是随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库已经无法解决如此丰富的需求，如果遇到这些问题，则需要继续优化。
2.11、第九次演进:引入NoSql数据库和搜索引擎等技术
2.11.1、架构图
2.11.2、架构描述
当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。
当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。
2.11.3、实战
暂无
2.11.4、所用技术
2.11.4.1、分布式文件系统
HDFS、Ceph
2.11.4.2、NoSQL数据库
键值数据库:Redis、Memcached
列族数据库：HBase、Cassandra
文档数据库：MongoDB
图形数据库：Neo4j
2.11.4.3、搜索引擎
Lucence、ElasticSearch、Solr
2.11.4.4、多维分析场景
Spark,Kylin
2.11.5、架构模式
略
2.11.6、面临的问题
引入更多组件解决了丰富的需求，业务维度能够极大扩从，随之而来的是一个应用中包含了太多的业务代码，业务升级迭代变得困难，需要继续优化
2.12、第十次演进:大应用拆分为小应用
2.12.1、架构图
2.12.2、架构描述
图中的每个应用都是一个tomcat集群，只不过没有画出来，这样拆分后，每个应用的更新迭代就不会互相影响。
2.12.3、实战
暂无
2.12.4、所用技术
按业务拆分应用，分布式配置：Zookeeper
2.12.5、架构模式
拆分
2.12.6、面临的问题
不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级。所以需要继续进行优化。
2.13、第十一次演进:复用的功能抽离成微服务
2.13.1、架构图
2.13.2、架构描述
比如一些用户，会员，支付等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP，RPC等请求方式来调用，每个单独的服务都可以由单独的团队来管理，我们可以借助类似SpringCloud，dubbo，SpringCloudAlibaba等微服务框架来实现，这些框架都提供了各种服务治理，服务配置，熔断，限流等解决方案，可以有效的保证微服务的稳定性和可用性。
2.13.3、实战
暂无
2.13.4、所用技术
SpringCloud，dubbo，SpringCloudAlibaba
2.13.5、架构模式
略
2.13.6、面临的问题
不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱，如果有需要的话可以继续进行优化。
2.14、第十二次演进:引入企业服务总线ESB屏蔽服务接口的访问差异
2.14.1、架构图
2.14.2、架构描述
通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。个人理解，微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。
2.14.3、实战
暂无
2.14.4、所用技术
这里用了ESB这种感觉“重工业”的技术，但是我觉得，这里如果对于一般的调用访问或许可以直接用网关替代，比如shenyu网关，后续可用服务网络类似Service Mesh
2.14.5、架构模式
略
2.14.6、面临的问题
业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于大促这类需要动态扩容的场景，需要随时水平扩展服务的性能，但是在扩展的时候需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难，所以要继续优化
2.15、第十三次演进:使用容器化技术实现运行环境隔离与动态服务管理
2.15.1、架构图
2.15.2、架构描述
目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。
在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响
2.15.3、实战
暂无
2.15.4、所用技术
docker,k8s,KubeSphere
2.15.5、架构模式
容器化
2.15.6、面临的问题
使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低
2.16、第十四次演进:以云平台承载系统
2.16.1、架构图
2.16.2、架构描述
系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。
所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：
IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。
2.16.3、实战
暂无
2.16.4、所用技术
云服务器
2.16.5、架构模式
公有云
2.16.6、面临的问题
至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论。
3、网站架构演变总结
3.1、’架构的调整是否必须按照上述演变路径进行？
不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
3.2、对于将要实施的系统，架构应该设计到什么程度？
对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
3.3、服务端架构和大数据架构有什么区别？
所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。
3.4、有没有一些架构设计的原则？
N+1设计。系统中的每个组件都应做到没有单点故障；
回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
监控设计。在设计阶段就要考虑监控的手段；
多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
资源隔离设计。应避免单一业务占用全部资源；
架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
使用商用硬件。商用硬件能有效降低硬件故障的机率；
快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
4、Java程序员开发网站要掌握的技术集合
4.1、基本技能
开发语言：Java,JavaWeb
Web相关开发框架：Spring,SpringBoot
数据库操作相关框架：MyBatis,Druid连接池
页面相关技术：HTML,CSS,JS,JQUERY,VUE
数据库技术：MYSQL,PostgreSQL
服务器：Linux
Web容器：Tomcat,Jetty,Undertow
缓存数据库：Redis,Ehcache,GuavaCache,Caffeine,Redis,memcached
消息中间件：RocketMQ
开发工具：SVN,MAVEN,GIT,IDEA,ECLIPSE
4.2、更多技能
分布式缓存:Redis
消息队列：RocketMQ,Kafka
键值数据库:Redis,Memcached
列族数据库：HBase,Cassandra
文档数据库：MongoDB
图形数据库：Neo4j
反向代理：Nginx,HAProxy
分布式数据库，读写分离、分库分表：MyCat,sharding-jdbc
Nginx负载均衡：LVS+Keepalived+Nginx
DNS轮询技术
分布式文件系统：hdfs(hadoop)、gridfs(mongo)、fastdfs、go-fastdfs、seaweedfs、MinIO、ceph、Cassandra
大数据分析：Spark
NoSql数据库：HBase,MongoDB,Neo4j
搜索引擎：Lucence,ElasticSearch,Solr
多维分析场景：Spark,Kylin
分布式配置：Zookeeper
微服务架构：Dubbo,SpringCloud,SpringCloudAlibaba
企业消息总线：ESB
服务网络：Service Mesh
容器：Docker
容器编排：Kubernetes(K8S),KubeSphere
云服务
人工智能
5、微服务架构技术选型
5.1、服务注册与发现
Spring Cloud Netflix Eureka
Spring Cloud Consul
Spring Cloud Zookeeper
Spring Cloud Alibaba Nacos
5.2、服务调用
客户端负载均衡器
Spring Cloud Netflix Ribbon
Spring Cloud LoadBalancer
RPC调用
Spring Cloud OpenFeign
Dubbo
5.3、服务限流熔断降级
Spring Cloud Netflix Hystrix
Spring Cloud Alibaba Sentinel
5.4、配置中心
Spring Cloud Config
Spring Cloud Zookeeper
Spring Cloud Alibaba Nacos
5.5、服务网关
Spring Cloud Netflix Zuul
Spring Cloud Gateway
5.6、分布式实物
Spring Cloud Alibaba Seata
5.7、服务链路跟踪
Spring Cloud Sleuth+Zipkin
Skywalking
5.8、服务安全
Spring Cloud Security
5.9、分布式消息
Spring Cloud Stream:RabbitMQ、Kafka、RocketMQ
