【原】从零开始改造淘淘商城（对项目的一些不足进行分析归纳）01

　　前言：

　　　　　　之所以想写记录这个系列是因为今年在不断学习新的东西和研究新的开源项目,偶然看到某机构的第一期淘淘商城的项目和视频,多多少少看了几集,前面课程较简单,后面的课程就稍微难一点，偏向运维这块。总体来说比较容易,适合刚入门的人看;相信不少人学习的时候也会有自己的观点和疑惑,当然我也不例外,所以带着这些东西我把淘淘商城这个项目重构了一遍。

        观后感：

　　　　 淘淘商城是典型的maven模块项目,其中pojo,service,mapper,controller单独划分为子模块,由taotao-manager统一管理,这也是目前互联网公司流行的开发模式之一。后续加入的restRESTful项目是为了提供给前端页面提供接口,这里顺带普及一下rest知识点：restRESTful可以通过一套统一的接口为 Web，iOS和Android提供服务,对外返回json格式数据。还有sso项目, sso项目是用来统一管理用户缓存信息,将用户信息存储到redis,解决用户只需要登录一次就可以访问所有相互信任的应用系统，而不用重复登录。

那么这个项目也存在一些问题,也是我自己思考后的一些疑惑,如下几点 ：

1. 尽管划分了模块但从总体来看项目还是属于单体垂直应用架构,因为从Controller->Service->Dao->Db都是一套流程下来,如果说某天改了dao需要发布版本那么整个网站都要shutdown后重新发布。

 2.对于数据访问,没有做对应的热点缓存,每次查询都去load数据库,主页访问量最多,同时并发量也凸显在这里,一个商城如果不做好缓存这块,那么数据库的IO分分钟就容易达到瓶颈。

 3. 跨域这一块,使用的是JSONP请求rest项目,但存在的问题是jsonp只支持get请求而不支持post请求,也即是说如果想传给后台一个json格式的数据,此时问题就来了,浏览器会报一个http状态码。

 4.sso存在一个问题是没有做到刷新用户的缓存时间,也就是从登录那一刻设置30分钟缓存时间,就算30分钟内我不断请求那么失效时间也不会更新。

 5.配置文件（xxx.properties不统一）

　　重构：

1. 引入dubbo分布式服务框架,减轻项目之间的耦合度,引入api工程,对外提供服务,注册中心使用的是zookeeper。
2. 新建taotao-config工程,统一管理配置文件,通过命名区分不同的模块对应的文件。
3. 引入spring-redis-session,解决sso的不足之处。
4. 接通支付模块,真正实现支付过程以及支付回调流程（这里对接的是某第三方支付测试环境）。
5. 新增队列功能,缓解下单这块的压力。
6. 优化redis,提取出redis服务给其他服务公用,目前taotao的redis服务如果其他服务也要用的话只能复制一份出去再配置一份。

最后：

下次的的博客章节会逐步分析和记录