架构设计原则
1.客户优先原则
架构设计需要考虑的东西太多了。
技术的：成本、可靠性、性能、可扩展性、复杂性、可测试性等
管理的：质量、投入、进度、人力水平等
抓住主要矛盾：客户需求。
2.适当超前原则
第一个原因：唯一不变的变化
第二个原因：首先满足客户需求，然后再超越客户需求
适当的意思：要超前，但不要超太多
架构设计的屠龙刀
"拆"与"合"
一个模块太慢了，拆成两个、三个
一个模块太负责了，拆成两个、三个
一台机器处理太慢了，拆成两台机器、三台机器
一台机器的可靠性太低了，拆成主备、集群
一块网卡太慢了，就拆成两块、三快
一根网线带宽太小了，拆成多根网线
一个机房可靠性不高，拆成两个机房
机房在中国不安全，拆成在中国和美国
拆也是有技巧的，有原则的
1.要拆应该拆的，不要到处都拆
2.不要使用暴力拆，要有技术的拆
架构设计的终极方法：拆，而终极难点是：合
以上表明，拆是手段，合才是关键。拆了之后，还有一件更重要的事，就是怎么把拆出来的模块整合起来。
拆的常见手段：
1.拆硬件
俗称的加机器，拆硬件可以得到两类经典的架构模式：主备模式和负载均衡模式。
主备模式：如mysql主从，主机负责写，从机负责读，主机同步数据给从机，从机间不沟通。
负载均衡模式：软件中的nginx、硬件的F5、网络的DNS
2.拆地点
【同城多机房】、【跨城多机房】、【跨国多机房】
3.拆功能
拆功能解决复杂性和可扩展性，一个系统拆成多个子系统，一般拆成3-5个系统比较适合。
例子：
1000TPS的架构：一台机器轻松搞定
1万TPS的架构：使用epoll的异步编程模式
10万TPS的架构：一台机器拆成两台
100万TPS的架构：拆成20台的服务器集群
1000万TPS 高可用的架构：拆成上海机房、纽约机房、印度机房，每个机房70台机器
合的常见手段：
1.客户端合：
Memcached的服务器集群拆分为三台服务器，但是这些服务器间没有交互，而是通过Memcached和苦短将这些机器合起来成为一个集群，好处是服务器端的设计很简单，缺点是客户端的设计比较负责，客户端需要保存服务器的信息列表，一旦增加、删除，客户端必须同步修改配置，复杂度很大。
2.合网络：
DNS、nginx
3.中间件合：
如TDDL，有了它之后，客户端不再直接连接数据库，而是连接TDDl，它可以完成分库分表、主备倒换、读写分离等，比较复杂、成本高
4.子系统合
子系统间互相调用
架构师要掌握坚实的知识和技能。
