4、部署架构
4.1 单机器
小型网站，阿里云小项目还有人在用。
1）方案
单台机器的性能很快达到上限，就是所说的资源不足了
然后开始提升配置，推动高配机器的发展，成本高昂
2）特点
部署简单：采用web包部署与发布，db等资源同台机器连接，简单易操作。（课题：tomcat源码剖析）
资源争夺：在业务发展的初始阶段尚可支撑，随着访问量的上升，单机性能很快会成为系统瓶颈。
4.2 角色划分
稍微大一点的系统，把数据库、缓存、消息等中间件剥离出去，单独机器来部署
1）方案
多台机器：tomcat与mysql各自独占机器资源
针对性扩容：tomcat应用机更注重cpu的运算和内存，mysql更注重io与磁盘性能，针对各自情况扩容
（课题：架构设计基础设施保障）
2）特点
数据维护：可以抽出单独的dba来维护数据库服务器
数据安全：需要跨机器访问数据库，链接密码需要注意防范泄漏
4.3 应用集群
2004-2005，淘宝V2.0，EJB为核心。V2.1架构下，引入spring框架走向轻量化和集群
1）方案
apache：早期负载均衡方案，性能一般
nginx：7层代理，性能强悍，配置简洁，当前不二之选（课题：openresty日活亿级用户流量控制）
haproxy：性能同样可靠，可做7层或4层代理。
lvs：4层代理，性能最强，linux集成，配置麻烦（课题：lvs+keepalived高可用部署实战）
f5：4层，硬件负载，财大气粗的不二选择
2）特点
session保持：集群环境下，用户登陆需要分布式session做支撑（课题：多维系统下单点登录的深入讲解）
分布式协同：分布式环境下对资源的加锁要超出线程锁的范畴，上升为分布式锁
调度问题：调度程序不能多台部署，容易跑重复，除非使用分布式调度，如elastic-job
机器状态管理：多台应用机的状态检测与替换需要做到及时性，一般niginx层做故障转移
服务升级：滚动升级成为可能，灰度发布（课题：不容忽视的灰度发布）
日志管理：日志文件分散在各个机器，促进集中式日志平台的产生（课题：集中式日志平台的深入应用）
4.4 多层代理
1）方案
机器规模进一步加大，动静态均有多个nginx负载，入口统一交给lvs负载。多层代理形成。
2）特点
机房受限：lvs依然是单一节点，即使keepalived做到高可用，流量仍然需要在唯一入口进入。
4.5 异地访问
淘宝V2.1时代 ， 使用自己的TaobaoCDN。
将相同的系统部署多份，分散到异地多个机房，或者电信、移动等多个网络中。
不同地点，不同网络接入的用户，有了不同的访问入口和选择。
1）方案
dns轮询：通过配置多个ip将服务部署到多个机房，通过dns的策略轮询调用，可以实现机房层面的扩容
CDN：就近原则，使用户获得就近的机房访问相关资源，自己投资太大，购买他方需要付费。
2）特点
基本解决了机器部署的扩容问题，随着业务的发展，扩容与收缩变得困难，促进资源调度层面的技术发展。
4.6 云平台
针对中台化的建设及微服务数量的飙升，部署和运维支撑同步进行着变革。面临微服务的快速部署，资源的弹性伸缩等挑战，容器化与云被推进。
案例：成百上千的服务数量庞大、大促期间某些微服务的临时扩容。
1）方案
虚拟化：vm方案，Openstack，Vmware，VirtualBox
容器化：docker
编排：swarm，k8s，k3s（课题：运维篇 docker，k8s深入原理与应用）
云化：容器化解决了资源的快速伸缩，但仍需要企业自备大量机器资源。推动私有云到企业云进化
2）特点
资源预估：注意资源的回收，降低资源闲置和浪费，例如大促结束后要及时回收。
运维要求：需要运维层面的高度支撑，门槛比较高
预估风险：云瘫痪的故障造成的损失不可估量，（openstack垮掉的事故案例）
5 架构思想
任何体系的成型不是一蹴而就，随着访问量，数据量的增长，业务需求在推动技术架构的发展变革。
- 知行合一，做之前，先考虑意义
- 原生优于定制，约定大于配置
- 什么都是，最后会沦落到什么都不是
- 控制技术欲，不要瞎折腾
- 留下扩展，但不要想到100年后
- 没有最好的，只有最合适的
- 够用就好，玩的越花，风险越大
- 简约最美
