背景
先从“赞”搜索的历史开始吧,概括总结一下,个人觉得主要分三个阶段:
1. 主业务阶段
2. 过渡阶段
3. 主服务阶段
架构
“赞”搜索平台围绕重存储轻搜索的场景(可以参见前面写的一篇文章“轻搜索的困局和破局之道”)而设计,在平台前面加上“轻量”两字,并不是指体量小,而是说业务多样性。
为了保证性能,整个平台的设计尽量精简,不做任何多余的业务逻辑,简单画个架构图:
大致介绍下主要的组成部分:
1. es-console
2. es-conf
3. es-proxy
4. es-toolbox
5. es
目标
“赞”搜索的核心架构要素:
1. 性能
proxy用了dubbo框架来作为服务载体,比较偏应用层,其实对于一个偏重数据存储的服务来说有点太高层次了些,个人比较倾向的方式是在client中嵌入proxy逻辑代码,这样既能保留原生的es访问方法,又能减少用户感知,不过现有资源不足以采用这种方案,作为后期优化方向。
主要的几个手段:
2. 扩展性
3. 可用性
稳定压倒一切,一个时不时宕机的平台是不会有未来的,可用性是“赞”搜索设计首要考虑的,主要的几点:
4. 伸缩性
结语
草稿打了好几遍,总是不合意,各位看官有什么意见和建议麻烦多提点提点~