目录
单体架构:
分布式
集群
负载均衡
分布式+集群+负载均衡
SOA
微服务
CDN
单体架构:
简介：所有功能都放在一个应用里.
优点：便于开发，测试，部署也很方便
缺陷：高访问，高并发的上限是固定的，一个服务有问题影响其他服务
比如一个单体架构，能够承受 1000次访问/秒。 但是访问量达到 2000次/秒的时候，就会非常卡顿，严重影响业务，并且仅仅依靠单体架构本身，很难突破这个瓶颈。
解决办法通常就是采用分布式和集群来做
分布式
简介：一个功能做成一个应用，相互不影响
优点：只要约定好接口可以让不同的团队开发不同的微服务,彼此之间是低耦合。 比如 一个银行 排队抽号服务挂了，不影响办理业务的服务
集群
简介：相同功能的应用 多复制几个都部署上去
优点：把2个应用部署在2个机器上，理论来说能够承受的负载就是 x 2 。一个挂了另一个还能用，高可用性。
负载均衡
集群后,一个请求到底该交给哪台服务器处理? 让每台服务器负载量均衡才能发挥最大的效果
分布式+集群+负载均衡
先用分布式思想 把大的工程拆分成一个个独立的子系统，然后每个独立的子系统建立集群，并实现集群的负载均衡
SOA
（Service-Oriented Architecture），面向服务的架构。
把系统水平分离成不同的服务层， 表现层，功能层，数据层.... 通过统一的 ESB或者dubbo对服务进行调用
微服务
相比SOA更注重垂直服务，每个微服务通常直接为用户提供某个功能
比如 手机端，桌面端，网页端各有一个比较类似的需求，
- 按SOA的思想是 把三个渠道拉一块，最后出一个兼顾到所有的需求，然后出一个大而全的服务
- 按微服务的思想 就把这个3个服务单独挖出来。然后针对性的快速和3个渠道确认业务需求，快速开发3个微服务投产
CDN
Content Delivery Network，即内容分发网络
CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。
但凡任何IT项目，有三个原则是要注意的：一，不要去折腾业务部门，要帮他们解决实际问题；二、花钱要花在看得见的地方，花小钱办大事；三、要尽可能争取更多干系人的支持，至少他们不反对。
吞吐量（TPS）、
QPS、
并发数、
响应时间（RT）
MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g） ，
Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。
