微服务架构实践：从零搭建网站扫码登陆

微信扫码登陆你们都是应用比较多的登陆方式了，如今大的购物网站像京东、淘宝等都支持使用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返回代码哟。