共计 3164 个字符，预计需要花费 8 分钟才能阅读完成。
微信扫码登录大家都是应用比较多的登录方式了，现在大的购物网站像京东、淘宝等都支持使用 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 返回代码哟。
