spring cloud微服务架构设计
1.概述
分别从总体层级、开发视图、部署视图三个角度，对整个系统的微服务架构进行“解剖”。总体层级关注调用的层级（从终端人机界面到物联网）；开发视图则主要面向开发人员，描述了系统工程结构、模块及关联关系；部署视图则是系统最终部署时的拓扑图；经过这些视角能够较为清晰的明白整个微服务架构设计思路。css
2.总体层级视图
自顶向下的一张调用层次关系图：html
详细的说明，见下方的开发视图和部署视图。前端
3.开发视图
下图仅对微服务部分进行描述，前端架构不是本文重点部分，在下一节的部署图中会做说明：vue
微服务开发视图展现了java开发环境中有哪些具体的工程、工程之间的依赖关系，关键点说明以下：html5
- 上图中的每个组件框表明了一个工程，全部工程都采用spring boot构建，都经过继承基础POM，经过maven来进行多工程之间的依赖管理；
- 右侧的基础工程以jar包方式被全部微服务工程引用，通用服务则是单独运行起来，供其全部工程以restful接口方式调用。
- 微服务目前划分为5个，分别是公式超市、行业记录、图库、用户子系统、共用服务，具体详细设计时会进行细化完善，设计为能够单独运行（启动多个独立进程），也能够合并（该工程经过引用jar包方式合并）在一个工程运行（启动一个进程），主要是视用户规模来定（代码工程为一套，只是打包时不同或做少许代码配置修改便可完成不一样的部署方式）；
- 微服务分为客户端和服务端，服务端支持HA部署，上图设计和下方部署设计中客户端不是直接调用服务端，也能够依据项目进度紧迫性要求，先可让客户端（前端）直接访问微服务，而是经过eurake注册中心，还有熔断、网关等服务经过spring cloud组件完成，只需少许配置便可。
4.总体部署图
部署图更为直观地展现了服务之间的调用关系、各服务部署状况。以下图：java
上图中调用关系看起来较复杂，按如下思路看图：node
- 实际上都是以服务注册中心和相关组件为中心，见上图中的橙色部分，这部分的服务均可以直接采用spring cloud提供的现成组件，除网关可能有较多业务代码外，其它只须要作少许配置便可，入门门槛很低；
- 业务类微服务，见下方中间部分是具体restful接口api，同常规的spring boot工程没有太大区别，关键在于充分的理解业务，进行较为合理的划分；
- 通用类服务，这部分主要一些通用服务，其中消息对列（kafka/emq/rabbitmq等）能够直接采用开源组件便可，认证受权是对整个受限访问资源访问控制，能够采用JWT方式进行认证，能够在业务类客户端调用，也能够在网关调用（或者直接写到网关代码中）； 消息推送服务，主要是对一些须要即时推送的消息进行当即推送服务，pc浏览器能够采用webstocket方式推送，手机端能够采用极光等第三方推送服务；
- 持久化部分，见左侧部分，分别对不一样的存储场景，使用不一样的存取方式，对大多数系统来讲可能只须要一个关系型数据库，但有些状况仍是须要用到nosql、分布多文件系统，但通常nosql用于解决关系简单大表的存储和查询，常规的业务仍是建议放到关系统数据库中；
- 右侧部分为客户端部分，这里有两种方式：
A.加入一层微服务客户端，主要为了更好的处理访问时的负载均衡、容断、restful服务； ios
B.直接调用网关，网关再调用具体的微服务，见上图中虚线部分； css3
无论采用哪一种方式，本案例中采用的是先后分离的开发模式，在ngnix中放置前端开发的代码（如vue.js+elementUI或bootstrap、layui等）直接配置到ngnix中或者用node.js启动后，在ngnix的配置文件中进行代理。web
最后看一下手机端，无论采用原生的开发仍是html5+css3方式开发，其调用接口将保持不变，建议通常要求不高的场景下采用html5开发，这样基本上前端人员便可完成移动端开发工做，原生开发则须要分别招聘andriod/ios开发人员。
5.总结
我的认为，其实大部分状况下中小型系统不适合采用微服务架构，一个系统跑下来，即便是一个小网站，也要启动不少服务进程，虽然解决了性能、HA单点问题，方便往后分模块进行升级，但对人员的要求相对要高不少，开发工做量要比单体应用高出不少，若是没有专业的团队，极可能实际的性能、可靠性反而下降了。另外开发微服务在开发过程当中也需解决不少低效的开发问题，如应采用代码生成器和造成不少团队开的规范的约定。