1 目标
一、 高可用、高并发、海量数据、高稳定性、容灾机制
二、 易扩展
三、 高效开发
a) 一种设计风格，将原本独立的系统拆分成为多个小型服务，这些小型服务都在各自独立的进程中运行。
b) 被拆分的每一个小型服务都围绕滋生系统中的某一项耦合度较高的业务活着功能进行构建，每个服务都有自己的数据存储，业务，自动化测试以及独立部署机制。
c) 服务与服务之间调用采用RESTful规范的api进行通信
四、 自动化测试与部署
五、 微服务是目前技术革命的主要趋势，传统单体应用的缺点有：
1. 随着业务增加，应用本身越来越臃肿，运维、开发难度增加；
2. 横向扩展性差，往往单体应用的并发瓶颈比较低，难以应对某些领域对高并发的需求，如电子商务、云应用等。
3. 本身可用性差，为了实现高可用，不得不应用 LVS+keepalived之类的其他支撑，二十年前的技术用到今天，各种配置又繁琐又笨拙，需要大量人力去进行维护，增加企业成本。
4. 单体应用的可持续化集成是伪命题，分布式应用的可持续化集成包括部署、运维、回滚等简单可控，非常适合大规模企业级应用。
六、 微服务应用的优点有：
1. 微服务本身是分布式应用，分布式应用是用来解决单体应用的压力问题的，即：分布式分散压力，微服务分散能力。基于功能对应用进行服务化拆分，提升开发效率，降低运维难度。
2. 分布式、微服务并不是很新的概念，就像VR在1980年代苹果就提出过VR概念。VR的大规模发展基于光学材料、图像处理技术的进步；而微服务的大规模发展，基于Dubbo，zookeeper的开源、netflix技术eureka、zuul、ribbon、feign的开源、spring-cloud的发布。
七、 国内的微服务解决方案有Dubbo+zookeeper，通过技术调研，Dubbo+zookeeper提供的服务治理、服务调用基于RPC，但是配置、使用比较复杂，要求开发人员有较高的技术学习能力。Spring-cloud是spring提供、基于spring boot的微服务解决方案，其基本好处有：约定大于配置、简化开发模式、屏蔽技术细节、专注业务代码。使用spring-cloud进行微服务开发非常简单方便，符合软件工程学，并不要求业务代码人员有架构、设计的能力，业务代码人员只需要拥有语言能力，按照设计人员的流程图、uml图、伪代码去实现业务代码即可。
2 架构思路
2.1 概述
一、 首先将业务按服务进行拆分
每个服务各司其职，集中力量完成自己的业务。服务的划分要“轻”、“微”。
上述服务只是一个示意，实际上会有更微细的拆分，比如对于高并发的主业务：订单创建会是一个服务，订单入库也会是一个服务，发邮件是一个服务，发短信也是一个服务。
二、 将数据库按业务拆分
为了突破数据库的并发瓶颈，将数据库按业务拆分，降低某个业务的数据库压力， 同时每个数据库提供高用的集群方式。
三、 服务之间通过服务接口调用来完成通信
当业务中有数据需要同步，或需要传递数据时，通过调用相应的服务接口来完成，这些接口的调用有的是同步的，有的是异步的。
四、 对外统一暴露服务网关
对于界面的渲染，以及用户的操作请求，通过统一的网关而不是一个个有服务，这有利于开发的一致性、有利于控制权限、有利于安全控制。
五、 服务的治理
面对众多服务，以及可能新增的服务，必须提供统一的注册及发现，使服务可以平滑的扩容，以发现新服务。
六、 断路器
当某个服务发生故障时，有可能会导致整个系统的瘫痪，比如某个关键服务的长时间不能响应，会逐步传递给其它服务，最终导致卡死。那么通过断路器的介入，当某个服务超出规范的响应时，或异常的响应时，直接断掉相应的请求，防止瘫痪传递。
七、 负载均衡
对于网关的请求，通过一定的策略，转发给相应的服务集群，使现负载均衡
八、 某服务的负载与扩容
以订单服务举例，基于spring boot开发一的一个服务，就是一个“胖jar”，无需关心tomcat在哪里，通过java –jar直接启动一个服务，将这个Jar复制一份再启动就再次提供一份同样的服务，尤其在Docker的配合下，这一切都变得极其简单，那么当某个服务压力上来，可以平滑的、简单的为某个服务扩容。
3 模块详述
3.1 页面生成交互图
3.2 模板服务交互图
3.2.1 会员维护
3.2.2 注册
3.2.3 登录
3.2.4 会话获取
3.3 商品服务
3.3.1 商品维护
3.3.2 商品详情显示
3.4 订单服务
3.4.1 加入购物车
3.4.2 购物车入库
3.4.3 购物车显示
3.4.4 结算页显示
3.4.5 订单创建
3.4.6 订单入库
3.4.7 订单维护
3.5 促销服务
3.5.1 促销维护
3.5.2 促销规则服
3.6 内容管理服务
3.6.1 内容维护服务
3.7 店铺维护服务
3.8 系统服务
