垂直拆分数据库时，会遇到的问题：
* 跨业务的事务
* 应用的配置项多了
关于事务的问题，有两种办法：
* 使用分布式事务
* 去掉事务或不追求强事务
– 某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈：数据水平拆分
将同一个表的数据拆分到两个数据库中
数据水平拆分会遇到的问题：
* SQL的路由问题，需要知道某个User在哪个数据库上。
* 主键的策略会有不同。
* 查询时的性能问题，如分页问题
– 使用搜索引擎：解决数据查询问题
– 部分场景可使用NoSQL提高性能
– 开发数据统一访问模块：解决上层应用开发的数据源问题
– 业务拆分及应用拆分
网站的业务日益复杂，建立一个独立的大型应用来完成这所有的业务变得不实际。从管理角度来，也不方便管理。然而，业务的拆分很难找到一种通用的模式，这是一个企业管理问题和技术问题的混合问题。同时和每个企业的具体情况有关。
但是从这两本书来看，最终架构都走向服务化，也就是SOA。而如何实现SOA，是另一个很大的话题，不是本篇文章的范畴。
我从程立08年的演讲中截个图来说明SOA后的架构大概是怎样的：
– 非功能性问题
– 安全性问题、监控问题
– 发布问题：新的架构意味着新的发布方式
– 分机房
这两本书都没有说分机房的问题。我没有经验，可是也可以猜到如果要分机房了，所有上面的问题都可能要重新考虑。
– 组织架构的变化
我们的技术架构的变化，势必会引起我们的组织架构的变化，反之亦然。
这部分看似不应该由我们来管，但是，我觉得，我们技术人员也要参与一部分的组织架构的设计。举个例子，组织架构的设计会涉及绩效，而绩效有时很像一个国家的法律。如果一个国家的法律不健全，会发生什么?你懂的。
同时，我们还必须考虑人员对新架构的学习成本。
这部分我目前在看相关的书籍，还没有一个系统的认识。
总结：
– 关于演进的顺序
在现实中，技术架构的演进不一定就是按文章从头到尾这样列下来的，所以，要视具体情况来下决定。
– 关于传统演进与现代有“云”环境下的演进
很可惜，只有李智慧谈到云，而且只点了一下——“现在越来越多人的网站从建立之初就是搭建在大型网站提供的云计算服务基础之上，所需的一切资源：计算、存储、网络都可以按需购买线性伸缩，不需要自己一点一点地拼凑各种资源，综合使用各种技术方案逐步去完善自己的网站架构”。
因为我用“云”的时间也不长，还不能总结出有云架构与传统的无云架构在演进的时候有什么不同。
说回传统的架构演进，我自己总结和思考的结果是：
在对网站进行架构调整时，可以从两大的维度考虑：数据服务和应用服务。而这个调整的过程中，需要分清当前哪个点是瓶颈，需要知道哪个点优化的优先级最高。同时，最重要的一点：我们虽然作为技术人员，也应该去学习业务知识，这样我们在考虑问题时分清哪些是业务问题，哪些是技术问题，分清后才能对症下药。你要知道有些问题用技术手段并不比用业务手段更有效。12306的分时卖票就是一个典型例子。
以上总结及思考有不对，欢迎斧正。非常感谢。