spring cloud微服务架构设计

 

1.概述

分别从整体层级、开发视图、部署视图三个角度，对整个系统的微服务架构进行“解剖”。整体层级关注调用的层级（从终端人机界面到物联网）；开发视图则主要面向开发人员，描述了系统工程结构、模块及关联关系；部署视图则是系统最终部署时的拓扑图；通过这些视角可以较为清晰的明白整个微服务架构设计思路。

2.整体层级视图

自顶向下的一张调用层次关系图：

详细的说明，见下方的开发视图和部署视图。

 

3.开发视图

下图仅对微服务部分进行描述，前端架构不是本文重点部分，在下一节的部署图中会作说明：

微服务开发视图展示了java开发环境中有哪些具体的工程、工程之间的依赖关系，关键点说明如下：

1. 上图中的每一个组件框代表了一个工程，所有工程都采用spring boot构建，都通过继承基础POM，通过maven来进行多工程之间的依赖管理；
2. 右侧的基础工程以jar包方式被所有微服务工程引用，通用服务则是单独运行起来，供其所有工程以restful接口方式调用。
3. 微服务目前划分为5个，分别是公式超市、行业记录、图库、用户子系统、共用服务，具体详细设计时会进行细化完善，设计为可以单独运行（启动多个独立进程），也可以合并（该工程通过引用jar包方式合并）在一个工程运行（启动一个进程），主要是视用户规模来定（代码工程为一套，只是打包时不一样或作少量代码配置修改即可完成不同的部署方式）；
4. 微服务分为客户端和服务端，服务端支持HA部署，上图设计和下方部署设计中客户端不是直接调用服务端，也可以依据项目进度紧迫性要求，先可以让客户端（前端）直接访问微服务，而是通过eurake注册中心，还有熔断、网关等服务通过spring cloud组件完成，只需少量配置即可。

4.整体部署图

部署图更为直观地展示了服务之间的调用关系、各服务部署情况。如下图：

上图中调用关系看起来较复杂，按以下思路看图：

1. 实际上都是以服务注册中心和相关组件为中心，见上图中的橙色部分，这部分的服务都可以直接采用spring cloud提供的现成组件，除网关可能有较多业务代码外，其它只需要做少量配置即可，入门门槛很低；
2. 业务类微服务，见下方中间部分是具体restful接口api，同常规的spring boot工程没有太大区别，关键在于充分的理解业务，进行较为合理的划分；
3. 通用类服务，这部分主要一些通用服务，其中消息对列（kafka/emq/rabbitmq等）可以直接采用开源组件即可，认证授权是对整个受限访问资源访问控制，可以采用JWT方式进行认证，可以在业务类客户端调用，也可以在网关调用（或者直接写到网关代码中）； 消息推送服务，主要是对一些需要即时推送的消息进行立即推送服务，pc浏览器可以采用webstocket方式推送，手机端可以采用极光等第三方推送服务；
4. 持久化部分，见左侧部分，分别对不同的存储场景，使用不同的存取方式，对大多数系统来说可能只需要一个关系型数据库，但有些情况还是需要用到nosql、分布多文件系统，但一般nosql用于解决关系简单大表的存储和查询，常规的业务还是建议放到关系统数据库中；
5. 右侧部分为客户端部分，这里有两种方式：

        A.加入一层微服务客户端，主要为了更好的处理访问时的负载均衡、容断、restful服务；

       B.直接调用网关，网关再调用具体的微服务，见上图中虚线部分；

不管采用哪种方式，本案例中采用的是前后分离的开发模式，在ngnix中放置前端开发的代码（如vue.js+elementUI或bootstrap、layui等）直接配置到ngnix中或者用node.js启动后，在ngnix的配置文件中进行代理。

最后看一下手机端，不管采用原生的开发还是html5+css3方式开发，其调用接口将保持不变，建议一般要求不高的场景下采用html5开发，这样基本上前端人员即可完成移动端开发工作，原生开发则需要分别招聘andriod/ios开发人员。

5.总结

个人认为，其实大部分情况下中小型系统不适合采用微服务架构，一个系统跑下来，即使是一个小网站，也要启动很多服务进程，虽然解决了性能、HA单点问题，方便日后分模块进行升级，但对人员的要求相对要高很多，开发工作量要比单体应用高出很多，如果没有专业的团队，很可能实际的性能、可靠性反而降低了。另外开发微服务在开发过程中也需解决很多低效的开发问题，如应采用代码生成器和形成很多团队开的规范的约定。