商城架构演变

2016-02-15  本文已影响0人  吕逸涛任春晚

性能

一开始的重点是提高服务的性能、反应速度,并且尽可能的保证系统的安全。

第一阶段

第一阶段

商城第一阶段的框架采用的是传统的动静分离+负载均衡的配置。

第二阶段

第二阶段框架的出现是为了解决第一阶段暴露出的几个问题:

因此,我们觉得最好能将HTML文件缓存下来

第二阶段

我们在Tomcat服务器上加上了EhCache过滤器。一些经常会被访问到的页面(譬如首页、商品详情页等)在第一次被访问过并成功生成HTML页面后,会被记录在内存中,下一次访问的时候就不会再向API服务器请求,也不会再解析Freemarker模板,内存中的页面会直接返回。

第三阶段

第二阶段的框架一上线就暴露出了问题:页面不能及时更新,需要等EhCache自带的缓存更新机制(通常是缓存池满了)激活,缓存才会更新;而我们需要缓存更新是及时的、是可控的。

所以,我们自制了一个叫Backbone的微服务

第三阶段

其实Backbone目前就被当成了一个定时任务系统,只不过起名的时候,我们对这个系统寄以重托,所以给了一个很大的名号。

工作流是这样的:

第四阶段

第三阶段的框架还是有瑕疵,有这么三个最为明显:

于是,我们采用了Ngnix+Lua的方式来解决上面三个问题。

第四阶段

Ngnix服务器Tomcat服务器生成的HTML文件保存到Redis中,这样Redis就被做成了Ngnix服务器集群统一存储HTML文件的地方。

优化

日志系统

经过四个阶段的性能优化,整个商城的服务应该算OK,接下来我们想让开发调试更轻松一些。

我们觉得目前开发调试的瓶颈是日志:

一种解决方法是将日志保存到专门的一台服务器,然后通过tail -f XX | grep XXX之类的命令来看。这种方法是能基本解决以上两个问题,但是不那么优雅,不能算作一个系统的解决方案。

于是,我们采用了ElasticSearch + LogStash + KinabaELK)。一开始我们想自己利用Bootstrap或者Framework7写一套系统,但是太懒,同时也发现ELK已经把我们想做的都做了,有些小功能,我们改改Kinaba就能实现,所以直接把ELK拿来用了。

首先我们自制了一个Admin微服务来监听处理Tomcat服务器通过MQ发送过来的日志

日志系统

日志服务的工作流是这样的:

小助手

最初的想法是利用Slack + Hubot,但是依然是因为懒,而转用了微信。

微信小助手的主要用处就是检查服务的上线状态,发送上线检查之类的关键字,就会激活我们写的检查程序,主要涉及商城页面能不能正常打开,有些流程能不能走通,如果走不通是因为跟API服务器的沟通断了还是API服务器坏了还是什么。其次还加上了一些权限设置以及小助手注册机制等等。

未完待续

之前坚持要自己做日志系统,还有部分原因是会根据分析日志得到的结果加上推荐系统和优化搜索。

未完待续
上一篇 下一篇

猜你喜欢

热点阅读