今天看了一篇"程序员"上的文章:"大众点评网的架构与实践",因为里面谈的架构演变之路中所经历的痛点对我的工作经验来说感同身受,所以觉得文章里的一些解决方案对我还是很有启发.文中的几点还是值得我们学习,实践下的.
文中提到的V1,V2阶段,也就公司起步阶段,其实这个时间还谈不上技术架构,此时更关注的是抢占市场,产品快速面世.这也是创业公司要注意的,在一开始的时候不要总想着用什么牛逼的技术和架构,更应该快速推出产品,初探市场反映以及快速变化.
V3架构中主要引入了如下技术: 缓存(Memcached),分布式文件系统,搜索引擎(Lucene),NoSql数据库(MongoDB). 引入的方案其实也是顺其自然的,就像文中所说,当访问量大起来了后,针对整个系统中的瓶颈,哪里痛就治哪里.缓存用来减轻db访问压力,分布式文件系统解决海量图片存储,Lucene提供信息检索能力(复杂查询无论从功能和性能上,数据库的全文检索都是满足不了的),NoSql数据库用来存储非结构化数据.基本有了这些架构方案后,一般的不是很复杂的应用都可以顶住.
在V3架构体系中我们都是从系统的性能瓶颈上做了相应的措施方案,优化访问速度上面做文章.但是随着业务的增长,相应的支撑系统也会越来越复杂,通常我们的系统不是一个项目就全部包括了,而是分成为很多小系统,从业务上分为不同的产品线,从功能上分为基础服务和应用服务,等等. 所以V4架构体系就是把大服务分成各个小服务去分别开发,管理. 比如用户管理系统,积分系统,结算系统,等等. 这样问题也就出来, 每个系统并不是孤立存在的, 它们要相互调用和依赖.如果其中的一个服务出现问题,往往会导致整个站点不可用.而且这种服务与服务之间的依赖的复杂度,会随着系统数量的递增而呈指数增长.相信每个开发员应都经历过种痛苦. 还有就是系统的增长与依赖,会大大增加运维部署的复杂度.
所以在V5架构体系中要解决和探索的问题依旧是"服务治理"的问题.文中提到用"泳道架构与容错隔离"方案,来提供系统的高可用性. 但是我个人觉得这种方案实施起来不是很容易,因为各泳道中的服务如果全部clone一套,对于资源的投入和部署升级的成本都还是挺大的. 在服务治理上, 可以借鉴阿里的经验,比如Dubbo,毕竟也是经历了亿级别调用的产品. 在服务注册, 发现, 负载上都是很好的实现.
在V5架构探索中,下面谈的几个方案如果利用起来,可以解决实际中很多问题:
- PaaS平台: 定制化容器,主要用于对基础组件的统一更新,配置加载管理. 使用业务开发人员只关注业务实现技术,对基础组件,公用框架透明.
- Cat统一监控平台: 对于分布式系统来说, 查看日志时,因为其整个行为操作分散在各个系统中,这对追踪整个事务是很不方便的.往往是根据某个标识(如用户id)在各个日志系统中人工连续起来.而Cat系统可以用统一的messageID记录日志,通过系统进行整合,形成各个维度的日志报表.
- code平台,使用github,对gitlib二次开发,可以pull request进行代码审查.
- 还有一些其它方面的探索和展望,这里就不再说了.因为每个公司发展一定阶段,都会在经历了各种痛苦的事情后会总结各种方案和开发辅助工具,帮助研发,运维人员去工作.