前台会员系统架构为分布式服务架构，不像后台管理系统的单一架构，所有功能都放在一起，按前端页面展示和后端业务逻辑划分层次。前台会员系统按照功能的类型划分工程模块，其架构图如下：
在分布式微服务中，功能被抽象成多个微服务，微服务之间只允许通过接口进行访问。为了使得微服务之间能互相找到对方，需要将所有微服务都注册到注册中心里。
在本架构中，微服务总共分成两大类，一类为数据中心，一类为业务逻辑相关的微服务。
数据中心中包含有两个微服务，
- 所有与关系型数据库MySQL相关的操作都在MySQL服务里；
- 而Redis服务中则主要包含Session共享功能，因为每个微服务之间都是不直接互通的，那么在A服务中进行了登录操作，由于不互通，在B服务中又要重新登录，这肯定是不可行的，因此需要将Session存储在Redis中，所有服务要用到Session时，都从Redis中获取。
数据中心是专门用来给业务逻辑相关微服务提供服务的，但是因为它们是直接操作数据的服务，处于保护数据的考虑，不能将它们的接口直接暴露给外界，要通过feign把接口暴露给 API 服务，而其他服务必须依赖 API 服务才能操作数据。
ii、业务逻辑跟业务逻辑相关的微服务有四个，分别为：
- 权限服务，包括登录、注册等功能；
- 项目服务，主要包含众筹项目的发起与展示功能；
- 订单服务，提供支持众筹项目的功能，因为需要填写各种信息，因此将其抽象为订单服务，就像淘宝订单一样；
- 支付服务，用户支持众筹项目后需要进行支付操作，这是一个很重要的功能，因此将其单独抽出来作为一个服务；
每一个服务都有各自的 ip:port 地址，处于保护服务以及方便用户的想法，我们不可能将这个地址暴露给用户，因此需要用网关服务来控制访问地址，如上图，用户访问服务都是通过网关，网关将请求转发到具体的微服务。
3、思考在开发这个尚筹网项目的时候我一直在想一个问题，我们为什么要这么去开发，因为这么一个架构供我开发让我觉得开发变得更加繁琐了，以及最近在实习的时候，我也遇到了这个问题。这里我们需要想清楚的事，分布式微服务架构不是为了让我们开发变得简便，确切说不是为了让我们开发初期变得简便，而是它具有的扩展性，我们觉得开发变得繁琐，是因为当前在开发的这个项目太小了，让我们认识不到分布式微服务架构的优点，正如一些创业公司，在创业初期其实没必要追求各种优越的架构，有些其实完全可以采用单一架构先造个原型，等以后时机成熟了再将其重构为分布式微服务架构，我想敏捷开发应该就是这个意思吧。
