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

1. 前言

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

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

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

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

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

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

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

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

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

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

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

第一步 - 分析业务

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

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

第二部 - 完成数据库设计

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

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

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

第四步 - 单位测试

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

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

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

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

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

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

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

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

微服务系统架构

整体以分层来处理：

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

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

它具备以下的特点：

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

Spring Cloud的常用子项目包括：

展开剩余53%