性能
一开始的重点是提高服务的性能、反应速度，并且尽可能的保证系统的安全。
第一阶段
商城第一阶段的框架采用的是传统的动静分离+负载均衡的配置。
- 最外层是采用
F5做的负载均衡和反向代理 - 两台
Ngnix服务器负责处理静态资源的请求，并将动态请求分发给Tomcat服务器集群 - 商城的应用（网站、触屏版等）都建立在
Tomcat服务器上，主要采用SpringMVC+Freemarker - 应用通过
API服务器暴露出的接口对数据库进行增删改查的操作
第二阶段
第二阶段框架的出现是为了解决第一阶段暴露出的几个问题：
-
Tomcat服务器过于忙碌：-
Tomcat服务器的一般工作流为：接收到Ngnix服务器转发的动态请求 => 将动态请求按照业务逻辑调用API服务器的接口 => 将API服务器返回的数据和Freemarker结合，生成HTML文件 - 对于经常被访问到的页面（首页、商品详情页等），
Tomcat服务器需要不断重复他的一般工作流，即使最后生成的HTML文件都是一模一样的。
-
Tomcat服务器和API服务器交互过于频繁：即使API服务器有如memcached类的缓存，依然会有很多不必要的网络消耗
因此，我们觉得最好能将HTML文件缓存下来
我们在Tomcat服务器上加上了EhCache过滤器。一些经常会被访问到的页面（譬如首页、商品详情页等）在第一次被访问过并成功生成HTML页面后，会被记录在内存中，下一次访问的时候就不会再向API服务器请求，也不会再解析Freemarker模板，内存中的页面会直接返回。
第三阶段
第二阶段的框架一上线就暴露出了问题：页面不能及时更新，需要等EhCache自带的缓存更新机制（通常是缓存池满了）激活，缓存才会更新；而我们需要缓存更新是及时的、是可控的。
所以，我们自制了一个叫Backbone的微服务
其实Backbone目前就被当成了一个定时任务系统，只不过起名的时候，我们对这个系统寄以重托，所以给了一个很大的名号。
工作流是这样的：
- 当有缓存的内容进入
EhCache的时候，Backbone会接收到请求的参数 -
Backbone根据接收到的请求参数，按照业务逻辑，请求API服务器；之后将API服务器返回的结果拼接，生成一个签名，最后将<请求参数，签名>存入Redis中 -
Backbone定期从Redis中取出请求参数，并按照页面逻辑，请求API服务器，如果API服务器返回的结果拼接后的签名和Redis中存的签名一致，则无变化；如果不一致，Backbone会删除Redis中的记录，并调用Tomcat服务器暴露的接口删除EhCache中该请求的缓存。
第四阶段
第三阶段的框架还是有瑕疵，有这么三个最为明显：
- 既然第二次访问同链接访问的是缓存的内容，为什么还要到
Tomcat服务器才处理 - 缓存的
HTML文件能不能看到 -
EhCache中存的很多数据都是冗余的
于是，我们采用了Ngnix+Lua的方式来解决上面三个问题。
Ngnix服务器将Tomcat服务器生成的HTML文件保存到Redis中，这样Redis就被做成了Ngnix服务器集群统一存储HTML文件的地方。
优化
日志系统
经过四个阶段的性能优化，整个商城的服务应该算OK，接下来我们想让开发调试更轻松一些。
我们觉得目前开发调试的瓶颈是日志：
- 一方面 因为正式环境需要堡垒机才能操作，如果需要通过看日志来解决问题，需要到堡垒机看日志或者让运维拖日志下来，整个流程非常的难受。日志不是什么生死攸关的东西，我们想要看到线上实时的日志。
- 日志中打印了很多很多的内容，使用
tail -f之类的命令，滚屏会非常的快，这样看日志太伤神了。我们想要更优雅、更简单的查看日志的方法。
一种解决方法是将日志保存到专门的一台服务器，然后通过tail -f XX | grep XXX之类的命令来看。这种方法是能基本解决以上两个问题，但是不那么优雅，不能算作一个系统的解决方案。
于是，我们采用了ElasticSearch + LogStash + Kinaba （ELK）。一开始我们想自己利用Bootstrap或者Framework7写一套系统，但是太懒，同时也发现ELK已经把我们想做的都做了，有些小功能，我们改改Kinaba就能实现，所以直接把ELK拿来用了。
首先我们自制了一个Admin微服务来监听处理Tomcat服务器通过MQ发送过来的日志
日志服务的工作流是这样的：
-
Tomcat服务器的日志会被发送到MQ的Exchanger -
Admin系统会将监听到的日志进行处理（Tomcat服务器的日志利用拓展log4j.appender，封装了一些附加信息），打印到admin-log.log文件中 -
LogStash会分析admin-log.log，并将分析的结果实时的放入ElasticSearch里 -
Kinaba为ElasticSearch提供了一个可视化的界面，在这个界面中，我们能筛选日志，能实时打印日志
小助手
最初的想法是利用Slack + Hubot，但是依然是因为懒，而转用了微信。
微信小助手的主要用处就是检查服务的上线状态，发送上线检查之类的关键字，就会激活我们写的检查程序，主要涉及商城页面能不能正常打开，有些流程能不能走通，如果走不通是因为跟API服务器的沟通断了还是API服务器坏了还是什么。其次还加上了一些权限设置以及小助手注册机制等等。
未完待续
之前坚持要自己做日志系统，还有部分原因是会根据分析日志得到的结果加上推荐系统和优化搜索。
