微服务架构 Spring Cloud 理解与思考

1. 前言

微服务是相对传统的单服务而言的，其实也是因为系统的复杂度增加而开始自然演化的一个过程。

2. 微服务的产生之前

传统服务，一般会是一个单应用，完成整个的业务逻辑闭包，包括用户管理、业务管理、运维与监控，运营服务等。

当业务逻辑还比较简单的时候，一个单应用相对开发和运维都比较简单，换句话说，你只用盯着这一个应用就行了。所以，对于一个小的开发团队来说，如果你的产品业务非常简单，我还是建议单应用是合理的。

其实早于微服务这个概念的提出之前，很多复杂的业务系统都已经开始模块拆分的建设，只是还没形成这样一个完整的概念。

在模块拆分的过程中，自然会将功能高内聚，业务低耦合的逻辑抽取出来，并以接口的方式对外提供服务。其中最简单直接的就是用户管理，并衍生出来的单点登录概念。

2.1 一个单点登录的例子

我们还是以单点登录这个例子来说：

对于用户来说，并不希望频繁输入用户名和密码来登录网站，他的期望是只用登录一次，并可以访问网站的所有服务。对于已经在生产环境跑了好几年的用户管理服务，该怎么实现呢：

• 种cookie的方法，这个方法最简单粗暴，在用户的浏览器中种下一个特殊cookie，新的业务应用只用判断该cookie是否有效就行。这个方案最大的优点，就是简单，基本不用修改用户管理的代码，但是带来的代价则是安全风险和跨域问题。
• 单独抽取用户管理服务，并形成通用模块，如果用这个方法，很好，已经有了微服务的概念了。你可以考虑这个服务设计的足够简单，例如只用管理用户名、密码、邮箱，是否登录的会话管理数据，其他的业务，如果需要登录，则首先自动跳转到该用户服务的登录界面，在完成登录验证后携带token自动跳转的业务界面，并由业务系统后台将该token向用户系统确认该用户是否登录。这个方案比较复杂，但是解决了上面的问题。

对于大型网站来说，把授权的逻辑与用户信息的相关逻辑独立成一个应用，成为用户中心。用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。

第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。

2.2 如何设计并上线用户中心服务

我们先不考虑微服务这个概念，如果你是一个开发人员该如何设计这个服务呢。

第一步 - 分析业务

用户中心的业务非常简单，由于不用考虑用户的权限，那么基本功能只用包括：用户的CRUD，用户的登录、登出、密码或账号的修改，第三方接入的Potal及token查询鉴权。

当然，如果需要更进一步实现，一点退出，所有业务都退出，则会更复杂点，我们这里不做这个考虑。

第二部 - 完成数据库设计

基本用用户信息，设计为一个表；第三方接入和管理需要一张表；当然还有OPLog用来记录用户的操作，包括登录、登出、密码及账号修改等。

第三步 - 接口设计及代码编写

我们需要设计友好的接口，以便自己的系统和其他业务系统的对接，目前流行的REST的接口就非常合适。

第四步 - 单位测试

完成代码开发后，我们需要写单元测试用例，来验证接口和数据是否符合预期。

第五步 - 提交代码，并交由运维人员部署，通知测试人员验证

在测试环境上验证功能开发的功能正确性，安全性和性能压力。并确认该版本的是否可以发布生产。

第六步 - 运维人员部署生产环境

一旦测试通过，在确认好发布时间后，一般来说，如果业务系统不能做到灰度发布，则需要选择一个对用户影响最小的时间点来发布，所以很多互联网公司都选择夜间来部署。

3. 微服务架构

上述是一个比较正常的系统设计及上线的过程，可以看见，即使在没有微服务的情况下，也可以运转正常，但是也存在一些问题：

• 自维护一套服务，其他业务无法自动发现该服务
• 高可用的严重依赖业务系统自身，也就是需要服务提供者通过F5、VIP等方式来防止单点问题
• 系统上线比较步骤比较复杂，无法完全做到Devops
• 烟囱式建设，导致资源的浪费

让我们以微服务的思维来考虑这个问题吧：

• 需要一个服务注册与发现系统
• 需要一个统一的配置中心，可以动态加载配置信息
• 需要熔断机制，如果业务量过载，可以自动停止该服务，而不影响整个业务平台
• 底层服务统一维护

我们引入一个基于Spring Cloud的微服务架构：

整体以分层来处理：

• 基础通用服务 - 包括注册发现、配置中心、消息队列等基础服务
• 核心业务 - 以spring boot方式来构建每个微服务，对复杂业务进行拆分
• 数据层 - 数据库用量存储结构化数据，缓存则提高热点访问的性能，而对象存储服务用来存储二进制文件等数据
• 监控与运维 - 通过监控软件来监控系统的运行状况，并能报警通知，或者可以按照预定规则实现应急处置。
• 负载均衡 - 引入ribbon来完成客户端主动负载均衡功能，不用依赖服务端来配置，减轻服务端的复杂程度。

这样一来，我们可以看到用户中心可以作为一个微服务来对外提供服务能力，更进一步：

• 各个业务模块，各自维护好自己的数据库即db，并提供好rest接口
• 面向Devops，需要将服务Docker化

4. Spring Cloud 微服务框架介绍

微服务的框架也有不少，但是影响最大的还是Spring Cloud，相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。

它具备以下的特点：

• 对微服务基础框架Netflix的多个开源组件进行了封装，同时又实现了和云端平台以及和Spring Boot开发框架的集成。
• 为微服务架构开发涉及的配置管理，服务治理，熔断机制，智能路由，微代理，控制总线，一次性token，全局一致性锁，leader选举，分布式session，集群状态管理等操作提供了一种简单的开发方式。
• 开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。

Spring Cloud的常用子项目包括：

• Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等
• Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署
• Eureka：一个基于rest服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移。
• Hystrix：容错管理工具，实现断路器模式，通过控制服务的节点,从而对延迟和故障提供更强大的容错能力
• Ribbon：客户端负载均衡的服务调用组件
• Feign：基于Ribbon和Hystrix的声明式服务调用组件
• Zuul：微服务网关，提供动态路由，访问过滤等服务
• Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能