oauth

协程（Goroutine） 我们知道 Go 中，存在一个 defer 关键字用于修饰一个函数或者方法，使得该函数或者方法在返回前才会执行，也就说被延迟执行，但又一定会执行。但其实 Go 中也存在类似的异步，或者说多线程的概念，但在 Go 中不叫作线程，而是叫协程。 协程相对于线程来说，是一个非常轻量级的东西，它在一个程序中，可以启动很多个。协程也称为 goroutine。goroutine 被 Go runtime 所调度，这一点和线程不一样。也就是说，Go 语言的并发是由 Go 自己所调度的，自己决定同时执行多少个 goroutine，什么时候执行哪几个。这些对于我们开发者来说很透明，只需要在编码的时候告诉 Go 语言要启动几个 goroutine，至于如何调度执行，我们不用关心。 启动一个 goroutine 简单，Go 语言为我们提供了 go 关键字，相比其他编程语言简化了很多，如代码: func main () { go fmt.Println( "码疯窝在香嗝喱辣" ) fmt.Println( "I am main goroutine" ) time.Sleep(time.Second) } 这样就启动了一个 goroutine，用来调用 fmt.Println 函数，打印"码疯窝在香嗝喱辣"，所以这段代码里，其实有两个 goroutine，一个是 main 函数启动的

前言 API裸奔是绝对不允许滴，之前专门针对这块分享了jwt的解决方案( WebApi接口裸奔有风险 )；那如果是微服务，又怎么解决呢？每一个服务都加认证授权也可以解决问题，只是显得认证授权这块冗余，重复在搞事情；IT大佬肯定容忍不了，对于微服务架构，统一的认证授权中心那是必须的。 随着.NetCore的发布，IdentityServer4随之而出，是.Net Foundation的成员之一，专门针对.NetCore而出的认证授权框架，当前.Net圈是比较火的啦；再配上微服务认证授权的必要性，我决定以此开始入手进行微服务架构学习分享； 主要的学习分享思路为敲代码为向导，如果遇到相关理论概念，结合代码案例进行解释，不在单独针对理论知识整理相关文章(主要是担心归纳总结不好，让小伙伴疑惑，所以就想着结合应用案例解释比较容易理解)。 正文 IdentityServer4 主要的功能就是认证和授权，其他功能这里先假装不知道；主要目的就是想用其统一保护各个微服务的接口；先来理解一下认证和授权： 授权(Authorization) ：在用户身份认证通过之后，授予用户访问资源的过程或是用户授予第三系统访问自己资源的过程，资源可能是个人信息、文件、数据、接口等；OAuth2是现在比较火的授权标准，对于授权流程，后续会举例说明； 在公司，假如小伙伴是领导，在出差或休假的时候，通常会通过口头、邮件

springSecurity总结： 一、Spring security框架简介 1、简介 一个能够为基于Spring的企业应用系统提供声明式的安全訪问控制解决方式的安全框架（简单说是对访问权限进行控制嘛），应用的安全性 包括用户认证（Authentication）和用户授权（Authorization）两个部分 。用户认证指的是验证某个用户是否为系统中的合法主体，也就是说用户能否访问该系统。用户认证一般要求用户提供用户名和密码。系统通过校验用户名和密码来完成认证过程。用户授权指的是验证某个用户是否有权限执行某个操作。在一个系统中，不同用户所具有的权限是不同的。比如对一个文件来说，有的用户只能进行读取，而有的用户可以进行修改。一般来说，系统会为不同的用户分配不同的角色，而每个角色则对应一系列的权限。 spring security的主要核心功能为 认证和授权，所有的架构也是基于这两个核心功能去实现的。 2、框架原理 众所周知 想要对对Web资源进行保护，最好的办法莫过于Filter，要想对方法调用进行保护，最好的办法莫过于AOP。所以springSecurity在我们进行用户认证以及授予权限的时候，通过各种各样的拦截器来控制权限的访问，从而实现安全。 如下为其主要过滤器 ： WebAsyncManagerIntegrationFilter : 将 Security 上下文与

OpenShift被其供应商——Red Hat称为“ Enterprise Kubernetes”。在本文中，我将描述OpenShift和Kubernetes之间的真正差异。由于Red Hat倾向于将其描述为PaaS，因此常常令人困惑，有时掩盖了 Kubernetes是OpenShift不可或缺的一部分， 并围绕它构建了更多功能这一事实。让我们深入研究一下两者之间的真正区别。 1. OpenShift产品与Kubernetes项目 Kubernetes是一个开源的项目（甚至框架），而OpenShift是一个产品是有多种版本。其中一个称为OKD的OpenShift开源版本。以前它被称为OpenShift Origin，但是Red Hat的一些“聪明”的人想出了这个新名称，它的意思是“推动Red Hat OpenShift的Kubernetes的Origin社区发行版”（？）。但是，让我们暂时忘掉名称，只关注其含义。 有几个： OpenShift Container Platform是一种产品，您可以将其安装在基础设施上，该产品包含订阅附带的付费支持 您需要为集群续订OpenShift订阅，并且随着集群的增长需要支付更多费用 Kubernetes有很多发行版，但这是一个项目，如果出现了故障，您可以主要依靠社区或外部专家（在某些情况下，它们有时可能比Red Hat支持的要好）

本文将介绍开源API网关Kong。在GtiHub搜索API网关类的开源产品，可以看到Kong网关常年都是排第一的位置，而且当前很多都有一定研发能力的企业在API网关产品选型的时候基本也会选择Kong网关，并基于Kong网关进行二次开发和定制。 API网关概述 简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。 内部的微服务对外部访问来说位置透明，外部应用只需和网关交互 统一拦截接口服务，实现安全，日志，限流熔断等需求 从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了： 大量适配器实现对遗留系统的遗留接口适配，多协议转换能力 进行数据的复制映射，路由等能力 对于两者，我原来做过一个简单的对比，大家可以参考。 对于API网关进一步的功能介绍，可以我前面参考文章：《 一文详细讲解API网关核心功能和API管理扩展 》。 基于Openresty开发API网关 在谈API网关前，我们先谈下Openresty。在前面文章谈到过，当前适合用于API网关的架构，一种是基于Openresty的，一种是基于Go语言的。

1.什么是OAuth2 OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。 2.应用场景 第三方应用授权登录：在APP或者网页接入一些第三方应用时，时长会需要用户登录另一个合作平台，比如QQ，微博，微信的授权登录。 原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、请求后台数据。 前后端分离单页面应用（spa）：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证，比如使用vue、react后者h5开发的app。 3.名词定义 （1） Third-party application：第三方应用程序，本文中又称"客户端"（client），比如打开知乎，使用第三方登录，选择qq登录，这时候知乎就是客户端。 （2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上例的qq。 （3）Resource Owner：资源所有者，本文中又称"用户"（user）,即登录用户。 （4）User Agent：用户代理，本文中就是指浏览器。 （5）Authorization server：认证服务器