性能
一开始的重点是提高服务的性能、反应速度，并且尽可能的保证系统的安全。
第一阶段
商城第一阶段的框架采用的是传统的动静分离+负载均衡的配置。
- 最外层是采用
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的ExchangerAdmin系统会将监听到的日志进行处理（Tomcat服务器的日志利用拓展log4j.appender，封装了一些附加信息），打印到admin-log.log文件中LogStash会分析admin-log.log，并将分析的结果实时的放入ElasticSearch里Kinaba为ElasticSearch提供了一个可视化的界面，在这个界面中，我们能筛选日志，能实时打印日志
小助手
最初的想法是利用Slack + Hubot，但是依然是因为懒，而转用了微信。
微信小助手的主要用处就是检查服务的上线状态，发送上线检查之类的关键字，就会激活我们写的检查程序，主要涉及商城页面能不能正常打开，有些流程能不能走通，如果走不通是因为跟API服务器的沟通断了还是API服务器坏了还是什么。其次还加上了一些权限设置以及小助手注册机制等等。
