前记

单点登录（Single Sign On）严格上来说和 OAuth2 没太大关系，只是 SSO 可以通过 OAuth2 实现。本文延续 OAuth2 初识的模式，看完原理写 Demo，在上一个 Demo 的基础上加以改造。

认证中心仍然是 QQ，然后子系统是 QQ 邮箱 + QQ 游戏，两个子系统除了配置上有少许差别外，基本一样。

代码：GitHub

原理参考单点登录原理，内容上有删改。

前提知识：

• session 和 cookie 的使用

前记

本文主要是理解 OAuth2 协议中的 state 参数的用意——防止第三方客户端被 CSRF 攻击。

Demo 依然是 OAuth2 初识中的 模拟 QQ 授权银行客户端（授权码模式）。

参考文章：
RFC 6749 – Cross-Site Request Forgery
OAuth2 CSRF攻击

前言

实习正好一个多月，现在回顾一下这一个月都干了什么收获了什么。

第1星期

第1星期主要是上级校验我动手做东西的能力。

头2天熟悉公司的规章制度，接下来就分派下了一个仿照现有功能的任务，包括前后端。要求在第一个星期内完成，也就是我需要在剩余的3天半内完成，本来认为任务挺简单的，数据库，现成 Demo 也在，除了任务描述的不是特别清晰外，其他都自我感觉良好，然后就开启了趟坑之路。

前记

OAuth2 可以方便第三方应用获取用户在其他应用的信息。

比如用 QQ 账户登录优酷，优酷就会先让用户登录 QQ，然后让用户确认授权优酷访问 QQ 上的信息，确认后优酷就获得了 QQ 的 OAuth 服务器返回的 token，之后就可以通过 token 访问到权力范围内的用户相关信息。

共同点：装配 Bean，写在字段或 setter 方法上。

@Autowired

Spring 的注解，来自 org.springframework.beans.factory.annotation.Autowired

默认按类型装配，也可以使用名称装配，但要配合 @Qualifier 注解。

依赖对象必须存在，如果要允许 null 值，可以设置 @Autowired(required=false)

前记

上两章粗略的使用了配置中心和客户端，这一章将开始使用服务链路追踪（SpringCloud Sleuth）。

服务追踪分析

微服务架构上通过业务来划分服务，通过 REST 调用，对外暴露一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。

随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：

前记

一开始我们就创建了一个注册中心，但是当成千上万个服务向它注册的时候，它的负载是非常高的，这在生产环境上是不太合适的，这章将把 Eureka Server 集群化。

前言

最近做项目，是在已有数据库基础上写业务，然后发现了很多本是外键的字段并没有设置外键约束。因为之前都是按照规范建数据表，所以对此有点奇怪，然后在网上找到了比较好的回答。

观点对比

大家共同观点：主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省了其它的工作。

矛盾焦点：数据库设计是否需要外键。这里有两个问题：如何保证数据库数据的完整性和一致性；在第一条的基础上对性能的影响。