從All-In-One到SOA——技術(shù)及架構(gòu)的演進(jìn)過(guò)程（三）

標(biāo)簽：

設(shè)計(jì)

服务化演进过程之技术演进

1 WebServer、数据库、文件从单一到分离

此时的ORM工具、事务控制手段、简化CRUD是重要的关注点。职责分离，针对需求不同对服务器进行不同的配置（或采购），对应将依赖程度较高。

2 页面缓存、数据缓存

为了提高响应速度和避免不必要的请求，增加了页面缓存；为了应对有限的I/O资源，增加了数据缓存。在对数据修改时，同时修改缓存内容。

随着数据越来越多，缓存也逐渐变成了分布式（Memcached、Redis等等），对于分布式缓存的使用主要存在几种情况：

1）每台缓存Server存储部分数据（按Hash、取余、一致性Hash进行key的分配）；

2）缓存可以分主备模式（优势时down掉一台机器不会影响key分布，劣势是会存在脏数据以及是否需要双写及双写的损耗）；

3）缓存是否需要持久化（即保证缓存服务重启后数据仍然存在），这对控制型的缓存数据尤为重要；

4）缓存数据Key的规则，需要确保在数据结构变化时，程序不会读到脏数据；

5）对于缓存数据的超时时间，可设置全局默认值，特殊情况特殊处理（需要与Key规则结合设定）。

3 WebServer集群

随着WebServer的增加，就需要进行负载均衡及状态信息同步（主要是用户的登录信息），这就需要在架构上对信息同步进行支持（比如将登陆信息放在缓存中或者通过Cookie判断）。

4 分库分表与读写分离

分库分表、读写分离都需要架构的支持，无论是在代码的数据访问层处理还是单独的数据库中间层。

在处理分库分表、读写分离时，最好要做到对开发人员的透明。此时需要制定通用的规则、规范（针对特殊情况需要有相应的处理方案）以保证开发人员的快速开发与程序的正确运行。

分库分表规则的设定一定要参考业务，不同的业务类型分库分表的规则也不尽相同。以人为中心的业务和以地区为中心的业务，其规则一定不同。规则的设置一定要在架构中支持，避免通过业务代码控制。在架构中支持的规则，一定要通过配置方式实现，便于修改及管理（关于配置管理的内容以后单独说明）。

5 NoSQL与搜索引擎

关系型数据库存储结构简单、查询速度慢，先天不适合处理复杂类型数据。NoSQL（Not Only SQL）的诞生在一定程度上缓解了这种紧张的局面（为什么是一定程度呢？）。

下面是关于NoSQL的一些简单说明，用以解释为什么会使用NoSQL。

NoSQL数据库主要分为四类：键-值存储数据库（如Redis）、列存储数据库（如HBase）、文档数据库（如MongoDB）、图形数据库（如 Neo4J）。每种数据库的特点、适用场景有所不同，具体内容可查找相关文档查看。NoSQL因为去掉了关系数据库的关系型特性，所以非常容易扩展。

一般MySQL使用的是Query Cache，当表更新后Cache就会失效，Cache性能不高。而NoSQL的Cache是记录级的，粒度更细、性能更高。另外NoSQL无须事先创建字段，可随意存储自定义数据格式，这也是其广泛应用的一个原因。NoSQL也有其不利的一面，历史短暂、在稳定性上与关系数据库（MySQL）比还是稍有逊色。

搜索引擎的出现大幅度的提高站内搜索速度，提升了用户体验，尤其是各种中文分词插件/工具的出现，让站内中文搜索结果的准确性大幅度提高，同时也缩短了用户在查找内容时的时间。