微信扫码登录大家都是应用比较多的登录方式了，现在大的购物网站像京东、淘宝等都支持使用APP扫码登录网站了。今天就用APP扫码登录网站的实例来举例说明微服务架构的搭建过程。

微服务架构应该是什么样子

在这之前先看一看一个微服务架构落地以后应该是什么样子的。平常所有的微服务架构更多的是从框架来讲的像Dubbo，SpringCloud等，从整个SpringCloud的生态来讲它也只包含微服务的一部分。因为微服务的拆分不可避免的造成了系统的复杂性，团队间的合作管理和持续的交付等等，都是一项比较复杂的工程，如果没有好的团队管理规范和持续交付的流程等微服务是很难落地的。

下面简单介绍一下上图中微服务架构的每一层的功能和作用：

基础设施层，这一项除非自己搭建IDC，基本上现在的阿里云、腾讯云和百度云等都已经很好的支撑，特别是对于小的公司来说，更节省成本。

平台服务层，对于现有的微服务能够快速动态部署那就是Docker了，再加上现有k8s等容器管理工具等，更是让微服务的部署如虎添翼，如果系统已经达到已经规模以后，可以考虑使用此种方式进行动态的扩容，一般情况下使用Docker就能解决部署问题了。

支撑服务层，这一层跟微服务框架贴的非常近了，像SpringCloud已经自带了很多功能，像注册中心、配置中心、熔断限流和链路跟踪等，Dubbo也自带注册中心。

业务服务层，这一层主要解决的是业务系统如何使用微服务进行解耦，各业务模块间如何进行分层交互等，形成了以基础服务模块为底层和以聚合服务为前端的“大中台小前台”的产品策略。

网关服务层，这一层解决了权限控制、外部调用如何进行模块的负载均衡，可以实现在该层实现权限和流量的解耦，来满足不同的端的流量和权限不同的需求。

接入层，该层主要是为了解决相同网关多实例的负载均衡的问题，防止单点故障灯。

微服务开发框架，现在流行的微服务框架主要是SpringCloud和Dubbo，SpingCloud提供了更加完整的生态，Dubbo更适合内部模块间的快速高并发的调用。

持续交付流水线，快速进行需求迭代，从提交代码到部署上线，能够快速的交付。

工程实践与规范，这一项做不好，那整个微服务实施起来绝对是痛不欲生啊，基础模块如何定义，基础模块如何与其他模块解耦，如何进行版本的管理这个我在之前的使用Git和Maven进行版本管理和迭代的方法进行了说明。

端到端的工具链，这里就是敏捷运维工具，从研发代码到最终上线到生产环境，任何一部都要有工具去实现完成，实现点一个按钮就能最终上线的系统。

以上讲了实现微服务架构应该要做哪些事情，现在可以想想你的微服务架构到底落地到生成程度了，闲话少说，书归正传，今天是用APP扫码登录网站这个功能来进行举例说明应该从哪些方面进行微服务的落地实践。

网站扫码登录功能

这个功能是指在网站上选择使用二维码扫码登录，网站展示二维码，使用已经登录的应用APP扫码并确认登录后，网站就能登录成功，这既简单快捷，又提高了安全性。现在实现扫码登录网站的技术基本上有两种，一种就是轮询，另一种就是长连接，长连接又分为服务器端单向通信和双向通信两种，服务端单向通信只能由服务器端向客户端一直发送数据，双向通信是客户端和服务器端可以相互发送数据。像微信、京东和淘宝都是采用轮询的方式进行扫码登录的，一直使用轮询的方式在请求服务器端。今天我设计的这个扫码登录的功能，是采用的长连接能够双向通信的WebSocket的方式实现的。

网站扫码实现流程

1.用户在网站上登录时选择扫码登录。

2.服务器端收到请求，生成一个临时的令牌，前端生成带令牌的链接地址的二维码，在浏览器上显示。

3.PC端同时要与后台建立起websocket连接，等待后台发送登录成功的指令过来。

4.用户用应用扫码，这个时候如果已经登陆过，后台就能获取到当前用户的token，如果没有登录到系统中，需要提前做登录。

5.用户在应用APP上已经显示了是否确认登录的按钮。

6.用户点击确认按钮，应用APP发起后端的api调用。

7.后端接收到调用，根据临时名牌向websocket模块发送当前用户的token，pc端接收到登录成功，跳转到用户个人首页。如果用户点击了取消按钮，会根据uid向websocket模块发送取消登录的指令。

技术的选型

1.微服务框架的选择

现在比较流行的是SpringCloud和Dubbo这两个框架，RPC的微服务框架还有Motan都不错，这里我使用SpringCloud和Dubbo这两个框架，使用SpringCloud实现网关和聚合服务模块并对外提供http服务，使用Dubbo实现内部模块间的接口调用。注册中心使用Zookeeper，Zookeeper能够同时支持SpringCloud和Dubbo进行注册。

2.Websocket框架选择

其实Spring现在已经具备websocket的功能了，但是我没有选择使用它，因为它只是实现了websocket的基本功能，像websocket的集群，客户端的管理等等，使用spring实现的话都得从零开始写。之前就一直使用netty-socketio做websocket的开发，它具备良好的集群、客户端管理等功能，而且它本身通知支持轮询和websocket两种方式，所以选它省事省时。

3.存储的选择

临时令牌存放在redis中，用来进行websocket连接时的验证，防止恶意的攻击，用户数据放在mysql中。

4.源码管理工具和构建工具的选择

使用Git作为代码管理工具，方便进行代码持续迭代和发布上线，使用Gitlab作为源码服务器端，可以进行代码的合并管理，使整个代码质量更容易把控。采用Maven做为构建工具，并使用nexus创建自己的Maven私服，用来进行基础服务版本的管理和发布。搭建Sonar服务器，Maven中集成Sonar插件进行代码质量的自动化检测。

5.持续构建和部署工具

采用Docker部署的方式，快速方便。采用Jekins做持续构建，可以根据git代码变更快速的打包上线。

模块功能设计

根据《微服务架构：如何用十步解耦你的系统？》中微服务解耦的设计原则：

1.将Websocket作为服务独立出来只用来进行数据的通信，保证其功能的单一性，独立对外提供SocketApi接口，通过Dubbo的方式来调用其服务。

2.将用户功能作为服务独立出来，进行用户注册和登录的功能，并对外提供UserApi接口，通过Dubbo的方式来调用。

3.对外展示的功能包括页面和静态文件都统一到WebServer模块中，需要操作用户数据或者需要使用Websocket进行通信的都统一使用Dubbo调用。

4.对于基本的权限认证和动态负载均衡都统一放到Gateway模块中，Gateway可以实现http的负载均衡和websocket的负载均衡。

5.如果访问量非常大时，就考虑将Gateway分开部署，单独进行http服务和websocket服务，将两者的流量解耦。

6.webserver端访问量大时，可以考虑将静态页面发布到CDN中，减少该模块的负载。

开发规范解耦公共服务

指定良好的开发管理规范，使用Git做好版本代码的分支管理，每个需求迭代使用单独的分支，保证每次迭代都可以独立上线，Maven私服中每次SocketApi和UserApi的升级都要保留历史版本可用，Dubbo服务做好多版本的兼容支持，这样就能将基础公共的服务进行解耦。

总结

微服务的引入不仅仅是带来了好处，同时也带来了系统的复杂性，不能只从框架和代码的角度来考虑微服务架构的落地，更要从整个管理的角度去考虑如何括地，否则使用微服务开发只会带来更多麻烦和痛苦。

长按二维码，关注公众号煮酒科技(xtech100)，输入数字11返回代码哟。