共计 4141 个字符，预计需要花费 11 分钟才能阅读完成。
我的公众号：MarkerHub，网站：https://markerhub.com
更多精选文章请点击：Java 笔记大全.md
小 Hub 领读：
有点高级，须要细细品读！
- 若汐缘
- https://www.jianshu.com/p/796…
前言
以淘宝网为例，简略理解一下大型电商的服务端架构是怎么的。如图所示
最下面的就是平安体系零碎，两头的就是业务经营零碎，蕴含各个不同的业务服务，上面是一些共享服务，而后还有一些中间件，其中 ECS 就是云服务器，MQS 是队列服务，OCS 是缓存等等，右侧是一些支撑体系服务。
除图中所示之外还蕴含一些咱们看不到的，比方高可用的体现。淘宝目前曾经实现多机房容灾和异地机房单元化部署，为淘宝的业务也提供了稳固、高效和易于保护的基础架构撑持。
这是一个含金量十分高的架构，也是一个非常复杂而宏大的架构，当然这个架构不是一天两天演进成这样的，也不是一开始就设计并开发成这样的，对于初创公司而言，很难在初期就预估到将来流量千倍、万倍的网站架构会是怎么的情况，同时如果初期就设计成千万级并发的流量架构，也很难去撑持这个老本。
因而一个大型服务零碎，都是从小一步一步走过去的，在每个阶段找到对应该阶段网站架构所面临的问题，而后一直解决这些问题，在这个过程中，整个架构会始终演进，同时内含的代码也就会演进，大到架构、小到代码都是在一直演进和优化的。所以说高大上的我的项目技术架构和开发设计实现不是欲速不达的，这是所谓的万丈高楼平地起。
单机架构
从一个小网站说起，一般来说初始一台服务器就够了，文件服务器、数据库以及利用都部署在一台机器上。也就是俗称的 all in one 架构。
多机部署
随着网站用户逐步增多，访问量越来越大，硬盘、cpu、内存等开始吃紧，一台服务器难以撑持。看一下演进过程，咱们将数据服务和应用服务进行拆散，给应用服务器配置更好的 cpu、内存等等，而给数据服务器配置更好、更快的大的硬盘，如图所示用了三台服务器进行部署，能进步肯定的性能和可用性。
分布式缓存
随着拜访的并发越来越高，为了升高接口的拜访工夫进步服务性能，持续对架构进行演进。
咱们发现有很多业务数据不须要每次都从数据库中获取，于是咱们应用了缓存，因为 80% 的业务拜访都集中在 20% 的数据上 (二八准则)，如果能将这部分数据缓存下来，性能就能进步很多，缓存又分两种，一种是 Application 中的本地缓存，还有近程缓存，近程缓存又分为近程的单机式缓存和分布式缓存 (图所示的是分布式缓存集群)。
咱们须要思考几点，具备哪种业务特点的数据应用缓存，具备哪种业务特点的数据应用本地缓存，具备哪种业务特点的数据应用近程缓存。分布式缓存在扩容时会遇上什么问题，如何解决，分布式缓存的算法都有哪几种，都有什么优缺点。这些问题都是咱们在应用这个架构时须要思考并解决的问题。
服务器集群
这个时候随着拜访的 qps 一直进步，假如咱们应用的 Application Server 是 tomcat，那么 tomcat 服务器的解决能力就会成为一个瓶颈，尽管咱们也能够通过购买更弱小的硬件但总会有下限，并且这个老本到前期是呈指数级的增长。
这时候就能够对服务器做一个集群(cluster)，而后增加负载平衡调度器(Load Balancer)，服务器集群后咱们就能够横向扩大咱们的服务器了，解决了服务器解决能力的瓶颈。
此时咱们又须要思考几个问题，负载平衡的调度策略都有哪些，各有什么优缺点，各适宜什么场景，比方轮询、权重、地址散列，地址散列又分为原 IP 地址散列、指标 IP 地址散列、最小连贯、加权最小连贯等等。
服务器集群后，假如咱们登陆了 A 服务器，session 信息寄存在 A 服务器上了，如果咱们的负载平衡策略是轮询或者最小连贯等，下次是有可能拜访到 B 服务器，这时候存储在 A 服务器上的 session 信息咱们在 B 服务器是读取不到的，所以咱们须要解决 session 治理的问题。
Session 共享解决方案
session sticky
咱们应用 session sticky 这种形式来解决这个问题，它的解决规定是对于同一个连贯中的数据包，负载平衡会将其进行 NAT 转换后，转发至后端固定的服务器进行解决，这种计划解决了 session 共享的问题。
如图所示客户端 1 通过负载平衡会固定转发到服务器 1 中。毛病是第一假如有一台服务器重启了，那么该服务器的 session 将全副隐没，第二是咱们的负载平衡服务器成了一种有状态的服务器，要实现容灾会有麻烦。
session 复制
session 复制，即当 browser1 通过负载平衡服务器把 session 存到 application1 中，会同时把 session 复制到 application2 中，所以多台服务器都保留着雷同的 session 信息。
毛病是应用服务器的带宽问题，服务器之间要一直同步 session 信息，当大量用户在线时，服务器占用内存会过多，不适宜大规定集群，适宜机器不多状况。
基于 cookie
基于 cookie，也就是说咱们每次都用携带 session 信息的 cookie 去拜访应用服务器。毛病是 cookie 的长度是有限度的，cookie 保留在浏览器上安全性也是一个问题。
session 服务器
把 session 做成了一个 session 服务器，比方能够应用 redis 实现。这样每个用户拜访到应用服务器，其 session 信息最终都存到 session server 中，应用服务器也是从 session server 中去获取 session。
要思考以下几个问题，在以后架构中 session server 是一个单点的，如何解决单点，保障它的可用性，当然也能够将 session server 做成一个集群，这种形式实用于 session 数量及 web 服务器数量大的状况，同时改成这种架构后，在写利用时，也要调整存储 session 的业务逻辑。
数据库读写拆散
在解决了服务器横向扩大之后，持续看数据库，数据库的读与写操作都须要通过数据库，当用户量达到一定量时，数据库性能又成为了一个瓶颈，咱们持续演进。
咱们能够应用数据库的读写拆散，同时利用要接入多数据源。通过对立的数据拜访模型进行拜访。数据库的读写拆散是将所有的写操作引入到主库中(master)，将读操作引入到从库中(slave)，此时应用程序也要做出相应的变动，咱们实现了一个数据拜访模块(data access module)，使下层写代码的人不晓得读写拆散的存在，这样多数据源的读写对业务代码就没有侵入，这就是代码层面的演变。
如何反对多数据源，如何封装对业务没有侵入，如何应用目前业务应用的 ORM 框架实现主从的读写拆散，是否须要更换 ORM，各有什么优缺点，如何取舍都是以后这个架构须要思考的问题。
当拜访量过大时候，也就是说数据库的 IO 十分大，咱们的数据库读写拆散又会遇到以下问题？
例如主库和从库复制有没有提早，如果咱们将主库和从库分机房部署的话，跨机房传输同步数据更是一个问题。另外利用对数据源的路由问题，这些也是须要思考和解决的点。
CDN 减速与反向代理
咱们持续减少了 CDN 和反向代理服务器 (Reverse proxy server)，应用CDN 能够很好的解决不同地区访问速度问题，反向代理则在服务器机房中能够缓存用户的资源。
分布式文件服务器
这个时候咱们的文件服务器又呈现了瓶颈，咱们将文件服务器改成了分布式文件服务器集群，在应用分布式文件系统时，须要思考几个问题，如何不影响部署在线上的利用拜访，是否须要业务部门帮忙荡涤数据，是否须要备份服务器，是否须要从新做域名解析等等。
数据库分库分表
这个时候咱们的数据库又呈现了瓶颈，咱们抉择专库专用的模式，进行数据的垂直拆分，相干的业务独用本人的一个库，咱们解决了写数据并发量大的问题。
当咱们把这些表分成不同的库，又会带来一些新的问题。例如跨业务和跨库的事务，能够应用分布式事务，或者去掉事务，或者不谋求强事务。
随着拜访量过大，数据量过大，某个业务的数据库数据量和更新量曾经达到了单个数据库的瓶颈了，这个时候就须要进行数据库的程度拆分，例如把 user 拆分成了 user1 和 user2，就是将同一个表的数据拆分到两个数据库当中，这个时候咱们解决了单数据库的瓶颈。
程度拆分时候又要留神哪些点，都有哪几种程度拆分的形式。进行了程度拆分后，又会遇到几个问题，第一 sql 路由的问题，假如有一个用户，咱们如何晓得这个用户信息是存在了 user1 还是 user2 数据库中，因为分库了，咱们的主键策略也会有所不同，同时会面临分页的问题，假如咱们要查问某月份曾经下单的用户明细，而这些用户又散布在 user1 和 user2 库中，咱们后盾经营管理系统对它进行展现的时候还要进行分页。这些都是咱们在应用这个架构时须要解决的问题。
搜索引擎与 NoSQL
在网站公布并进行了大规模的推广后，导致咱们应用服务器的搜寻量又飙升，咱们把应用服务器的搜寻性能独自抽取进去做了一个搜索引擎，同时局部场景能够应用 NoSQL 来进步性能。同时咱们开发一个数据对立的拜访模块，同时连着数据库集群、搜索引擎和NoSQL，解决下层利用开发的数据源问题。
后序
这里只是简略举例，并没有根据什么理论的业务场景。事实上各个服务的架构是要依据理论的业务特点进行优化和演进的，所以这个过程也不是完全相同的。当然这个架构也不是最终状态，还存在很多要晋升的中央。
例如负载平衡服务器目前是一个单点的，如果负载平衡服务器拜访不了，那么后续的包含服务器集群等也就无法访问了。所以能够将负载平衡服务器做成集群，而后做一些主从的双机热备，同时做一个主动切换的解决方案。
在整个架构的演进过程中，其实还蕴含更多须要关注的内容，比方安全性、数据分析、监控、反作弊 ……
针对一些特定的场景例如交易、充值、流计算等应用音讯队列、任务调度 ……
整个架构持续倒退上来，做成 SOA 架构、服务化 (微服务)、多机房 ……
最初，我想说高大上的我的项目技术架构和开发设计实现绝不是一僦而就的。
举荐浏览
Java 笔记大全.md
太赞了，这个 Java 网站，什么我的项目都有！https://markerhub.com
这个 B 站的 UP 主，讲的 java 真不错！
太赞了！最新版 Java 编程思维能够在线看了！
