架构之路
2015 年 02 月 18 日
architecture
-
Web服务器 + DB服务器
- 记得自己写的第一个web应用，也就是一个最基本的Servlet + JSP的小网站， 那个时候对应用架构也没有什么概念，只是想这那样做而已，应用架构也很简单。
-
代理服务器 + Web服务器 + DB服务器
- 但通常如果我们不会直接将web服务器提供的服务直接暴露给用户，我们需要一个前端代理服务器，如 Apache, Nginx等， 这样有便于我们作一些如安全，缓存，静态文件，分流等处理，而不是直接在WEB服务器里直接完成。
-
多WEB服务器
- 当单个web服务器已经很难较快响应用户请求(吞吐量过低)， 此时我们也许需要多个web服务器，让代理服务器通过负载均衡进行分流处理。
- 如果当我们WEB服务器数量已经比较多时，这时也许需要扩展多个代理服务器，每个代理服务器映射一个WEB服务器组。
-
缓存和数据库
- 由木桶原理可知，即便WEB服务器能及时收到客户端请求，但是最终可能因为数据源的压力过大， 同样导致响应时间增长，这时我们也许需要做的就是DB Master/Slave部署，基本原理可见之前的文章，或者提供缓存服务器。
- 对于缓存，会比较多用一些KV数据库 (如Redis, Memcached等)， 利用其内存式数据，可以高效获取到缓存数据。
-
本地缓存 + 通知
- 对于缓存我们可以将缓存放在WEB服务器本地(而不是分布式数据库中), 比如利用Guava的Cache API 来实现不同策略的缓存。但可能遇到一些比较实时的缓存数据，会造成多个WEB服务器的缓存数据不一致， 这时就需要通知其他WEB服务器数据需要刷新，可以利用 Redis Pub/Sub， Zookeeper Watcher， 消息队列等来实现通知。
-
服务化
- 当系统业务越来越多时，单个系统会变得越来越庞大复杂，这个时候我们需要将系统拆分开来， 将一些核心基础的服务作为单独的服务中心，这样各自的业务系统可以直接调用这些独立的服务，而 自己特有的业务只需自己实现即可。常用的Java服务化框架有淘宝的 Dubbo， 当当的DubboX等。
-
搜索
-
服务解耦
- 当服务模块越来越多时，服务之间的依赖关系有可能就变得比较复杂，或者说比较重，一个服务就被多个服务所依赖， 那么这个服务将变成一个依赖瓶颈，一旦该服务不可用，则有可能影响比较大，如下面这种:
- 这里短信服务已经被多个模块所依赖，这时我们可能就需要进行解耦，即通过一个中间层解除服务之间的，其中消息中间件(MQ)无疑是比较好的解决方案:
我相信每一个工程师都会有自己心中的架构之路，无论你从事过什么样的产品项目开发，系统总是会有自己的架构， 在产品生命周期过程中，架构也是会随之慢慢演进，改善的，而不可能一步到位，特此用一篇文章来记录自己所感， 可能有些凌乱，但会慢慢改进。
搜索作为一个站点比较基本的功能，通常是不太可能直接查询数据库， 特别是用户相关的系统，我们通常会先将需要查询的数据建立索引，在查询时，只需到索引库中进行查询，一旦建立了索引， 就应该想到什么时候更新索引，特别是一些比较实时的业务数据等。当然，不是只有需要搜索的数据才能使用搜索技术， 前台大部分数据库都可以使用搜索技术，这不仅减小数据库的压力，也会使得系统查询能力得到很大提升。常用的搜索实现有 Lucene， Solr， ElasticSearch(推荐)。
好人，一生平安。