架构设计三原则：
极客时间上阐述了一些在做开发过程中会遇到的问题，比如，在开发过程中，是跟着业务的最前沿的技术走，去让员工学习陌生技术，还是用大家都已经比较熟悉的业务。比如大家都使用MySQL比较熟悉，是选择MySQL还是业务能力更强的Mongo呢？如果做一个电商网站，是不是直接照搬淘宝就可以了呢？
架构设计的时候遵循三个原则：合适原则、简单原则、演化原则
合适原则：合适优于业界领先。再好的梦想也要脚踏实地，罗马不是一天建成的，冰山下面才是关键。不要想着几个人组成的小团队，就想在短时间内实现大公司的领先技术。
简单原则：简单优于复杂。组件越多，逻辑越复杂，就会越容易出现故障。
演化原则：演化优于一步到位。联想一下windows和Android的发展历史即可。
分库：
对于大型的数据库来说，如果将数据存储到单一的数据库服务器中，那么一旦遇到某些不可抗力，比如机房失火、或者设备老化，就会对该数据库造成毁灭性打击。这时，我们不仅需要对数据库服务器进行备份，同时要进行一定的分库。一般的分库是根据业务逻辑划分的。什么是业务呢？数据+逻辑=业务。比如说现在有一个购物网站，可以把用户信息，商品信息，购物车分成三个数据库。但是这也会带来问题，就是在查询的时候，不可以使用join了。同时会相应地增加查询的复杂度。
分表：
在同一个数据库中，拿用户信息来说，对于阿里的淘宝这种大业务来说，商品的信息少说也得有上亿，如果都将他们存放到一个表中，势必在查询索引的时候，会增加很多的时间，导致系统性能的下降。这时，就可以采用一定的分表策略了。
从直观上将，分表策略可以分为两种，水平拆分和垂直拆分。数据库里面，一列称为一个字段，一行称为一个记录。故而，垂直拆分，面对的拆分对象是字段。拆分的原则往往是根据业务需求的索引频率决定的。例如对于商品信息，我们可能更多的关注，名称、价格、生产厂商、购买量，而对于型号这种东西并没有特定的需要，除非我们已经从之前的那些信息中知道该商品为我们所需要的商品，才会点进去选型号。于是，就可以把型号这部分信息首先切割出来，并不直接展示给用户。水平拆分，面向的是记录，这个很容易理解。水平拆分的核心在于其路由策略。
水平拆分的路由策略大致可以分为两种，一是范围路由，二是Hash路由。
首先先来看范围路由，比如有1亿条记录，每条用户会有一个id，我们可以每100万条作为一个字表。根据id在的范围将该条记录放入对应的字表中。这种方法扩充字表很方便，前面的记录都不用动，直接在后面加即可。但是，这种方法有一个缺点在于，可能造成记录在各个字表中的分布不均匀。比如某一个字表中有几百条记录，另外一个字表中可能有几十万条。
第二种方法是Hash路由，该路由策略的优缺点刚好与水平路由相反。Hash路由就是选取某一列或者某几列的值进行Hash计算，根据计算的结果来决定这条记录存在哪个库的哪个表中。举个最简单的粒子吧，比如我们规定id%10的值作为表的名称。这种方法的优点就在于记录的分布比较均匀，缺点在于，不知道应该设置多少个初始的表，如果想要增加表，那么所有的记录都要进行重新排布。
分库分表的优化方案：
既然分库，分表都存在一定的问题，那么该如何进行优化呢？以下是GeekTime上的网友提出的几种优化方案：
1.做硬件优化，例如从机械硬盘改成使用固态硬盘，当然固态硬盘不适合服务器使用，只是举个例子
2.先做数据库服务器的调优操作，例如增加索引，oracle有很多的参数调整;
3.引入缓存技术，例如Redis，减少数据库压力
4.程序与数据库表优化，重构，例如根据业务逻辑对程序逻辑做优化，减少不必要的查询;
5.在这些操作都不能大幅度优化性能的情况下，不能满足将来的发展，再考虑分库分表，也要有预估性
为什么企业不适合使用固态硬盘？
看到优化方案一，我不禁产生了疑问，为什么企业的服务器都固守机械硬盘而不使用固态硬盘呢？特意地去了解了一下。机械硬盘虽然存取较慢，但是总体经过几十年的发展，已经较为成熟，如果出现损坏，可以使用一定的方法进行修复，把这部分数据找回来。相反，固态硬盘快是快，但是，数据丢失了不好找回。与此同时，企业使用的机械硬盘一般最小是2T，但是固态硬盘的话，很少有1T以上的。成本是很重要的因素，相同容量的硬盘，固态比机械要贵好多好多，这对于需要大容量存储的企业来说，成本翻了好多。