您好、欢迎来到现金彩票网!
当前位置:热购彩票app下载 > 公钥构架 >

微服务架构下的统一身份认证和授权

发布时间:2019-07-29 13:11 来源:未知 编辑:admin

  本文讨论基于微服务架构下的身份认证和用户授权的技术方案,在阅读之前,最好先熟悉并理解以下几个知识点:

  当企业的应用系统逐渐增多后,每个系统单独管理各自的用户数据容易行成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进。当企业的互联网业务发展到一定规模,构建统一的标准化账户管理体系将是必不可少的,因为它是企业互联网云平台的重要基础设施,能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力,为企业带来诸如跨系统单点登录、第三方授权登录等基础能力,为构建开放平台和业务生态提供了必要条件。

  在微服务架构下,必须对企业的平台生态进行合理的业务划分,每个业务板块将自成系统,例如负责宣发的企业官网、主打文体的 B2B2C 商城、面向社区的物业服务系统等,这些系统业务比较独立,应当独立拆分。每个系统又可根据各自的业务模型进行切分,将业务模型和用户需求统筹分析后建立恰当的领域模型,形成独立的服务。

  另外,企业平台的客户范围比较复杂,有 2B 的业务,也有 2C 的,还有 2G(goverment)的,因此平台级的统一身份管理必须涉及组织实体和个人实体两类,其中组织实体包括政府机关(G)、企业单位(B)、团体组织(B)等,这类似于多租户架构的概念,但又比传统多租户架构复杂。

  统一身份管理(UIM)是整个平台帐号和权限管控的基础,由此构建的系统称为UIMS(Unified Identity Management System),平台下所有系统的账户管理、身份认证、用户授权、权限控制等行为都经由 UIMS 处理,提供帐号密码管理、基本资料管理、角色权限管理等功能。UIMS 基于『统一身份治理』的概念,可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类,个人实体从属于组织实体,也可以不从属任何组织实体,且个人实体可同时从属于多个组织实体;基础权限模块将各业务系统的资源权限进行统一管理和授权;基础信息模块用于描述组织实体和个人实体的基本信息,如组织实体名称、地址、法人,个人实体姓名、电话号码、性别等基础信息。UIMS 提供统一的 API 与各子系统连接。

  可以看到,众多系统和众多服务都将依赖于 UIMS 。本文仅涉及 UIMS 下的身份认证和用户授权这两块,即两级账户体系和基础权限模块,据此可以独立出账户服务和鉴权服务,也可以合并成一个账户鉴权服务。

  关于统一身份管理系统的介绍,请参考平台级SAAS架构的基础-统一身份管理系统.html

  企业提供对外的 IT 服务,有两种部署模式:一是私有云部署,二是公有化服务。公有云服务即 SAAS,提供系统级的应用服务,包括企业服务如企业邮箱、办公 OA、人力资源系统等,个人服务如个人邮箱、云笔记、云网盘等。平台级的 SAAS 应用架构,实际上是一种多租户架构的升级版,加大了统一身份治理的难度。而基于 UIMS 系统的两级账户体系,可以很容易做到这一点。值得注意的是,有些系统仅提供个人账户服务,有些系统仅提供组织账户服务,有的则两者都提供,必须处理好个人实体和组织实体之间的关系。

  在 UIMS 中,组织机构应当是一种实体,与之对应的另一种实体是个人实体。注意实体(Entity)不是账户(Account),因此要设计一种用于组织实体登入受控系统的方法,这里有两种可选方案:一是增加组织实体账户,组织实体自身拥有账户,可直接进行认证登录;二是将从属于组织实体的个人账户作为组织实体的登入凭证。无论何种方法,在认证和授权时,都应当向 UIMS 提供统一的标准的账户凭证,凭证的规格由 UIMS 定义,因此,组织实体的认证授权与个人实体的认证授权并无二致。

  企业平台涉及众多子系统,为简化各子系统的用户管理,提升用户体验,因此实现 SSO 是统一身份认证的重要目标:一次登录,全部访问。对于企业内部应用来说,SSO 是必须的选项,例如企业 OA、HR、CRM 等内部系统;对于外部应用来说,SSO 是可选项,具体哪个应用应当加入 SSO 系统,由该业务系统决定,例如外部商城、物业系统等对外服务系统。无论何种应用是否采用 SSO,UIMS 在技术上应当具备 SSO 的能力。

  随着平台业务的逐渐增长,依托于平台的,和平台依托的厂商和客户等资源将极大的丰富平台,因此必须构筑开放的生态系统,以支撑业务的进一步发展。必须开放平台级的授权登录功能,以允许第三方应用接入。通过三方授权登录,将平台的服务各能力开发给第三方,并将第三方的服务和能力接入平台,繁荣共生,共同发展。

  业务系统切分出不同的服务,根据粒度粗细和业务需求不同,服务的数量和权限要求都不同。微服务架构下的身份认证和授权,可分为两种:

  通常,内部服务处于安全的内网环境之下,例如鉴权服务、商品服务、订单服务等,在对安全需求不高的情况下,可不执行认证过程,服务与服务之间是相互信任的。

  而外部服务的认证和授权,通常由外部应用发起,通过反向代理或网关向安全边界内的服务发起请求,因此必须执行严格的认证过程。无线端APP、Web端、桌面客户端等外部应用下的各类服务,都属于外部服务。

  与 SSO 相对应,UIMS 应该支持一次登出,全部登出,即 SSOff(Single Sign-Off,非标准术语);或者一次登出,部分登出,而是否全部登出或部分登出取决于用户的选择,例如用户在 Web 端登出后,是否无线端 APP 也登出,这取决于用户偏好,但系统应当提供这种能力。

  此外,必须提供统一的销毁功能,以支持用户删除其账户,一次销毁,全部销毁。

  云平台应具备付费授权机制,针对用户账户和组织账户进行独立授权。根据产品的商业策略,可执行灵活的付费模式:

  上文基于『统一身份治理』的理念,提出了统一身份管理系统(UIMS)下关于身份认证和授权部分的主要需求。目前实现统一身份认证和授权的技术手段较多,总体可以归纳为以下两类:

  分布式 Session 是老牌的成熟解决方案,但因其状态化通信的特性与微服务提倡的API导向无状态通信相互违背,且共享式存储存在安全隐患,因此微服务一般不太采用。

  OAuth2.0 是业内成熟的授权登录解决方案,然而 OA2.0 提供了4种授权模式,能够适应多种场景,作为基于令牌的安全系统,可以广泛用于需要统一身份认证和授权的场景。

  JWT(JSON Web Token)是一种简洁的自包含的 JSON 声明规范,因其分散存储的特点而归属于客户端授权模式,广泛用于短期授权和单点登录。由于 JWT 信息是经过签名的,可以确保发送方的真实性,确保信息未经篡改和伪造。但由于其自包含的客户端验签特性,令牌一经签发,即无法撤销,因此单纯采用 JWT 作为统一身份认证和授权方案无法满足帐号统一登出和销毁、帐号封禁和解除这几种类型的需求。

  CAS 是时下最成熟的开源单点登录方案,包含 CAS Server 和 CAS Client 两部分。CAS Server 是一个 war 包需要独立部署,负责用户认证;CAS Client 负责处理对客户端受保护资源的访问请求,需要认证时,重定向到 CAS Server。值得注意的是,CAS 是一个认证框架,其本身定义了一套灵活完整的认证流程,但其兼容主流的认证和授权协议如 OAuth2、SAML、OpenID 等,因此一般采用 CAS + OAuth2 的方案实现 SSO 和授权登录。

  在微服务架构下,身份认证和用户授权通常分离出来成为独立的鉴权服务。在做技术选型时,应从以下几点考虑:

  综合考虑,推荐采用无状态 API 模式,其中 OAuth2.0 能够完全满足。此外 JWT 除了不能满足 SSOff 外,其他都能满足,且是所有方案里最为简便轻巧的一个,可通过搭配 API 网关来满足 SSOff 特性的要求,因此 JWT + API 网关也是一个推荐的方案。

  为便于理解统一认证和授权方案的细节,假定一种场景:团队准备构建一套基于图像的物品识别系统,允许用户通过 H5 应用或 APP 上传图像,系统分析后返回识别结果;同时期望将此系统开放给社区和行业用户以便商用;最后允许第三方应用将自身的功能接入 IBCS 以增强后者的能力。

  在微服务架构下,IBCS 分为内外两层,内层处于物理内网环境下,也称为内部服务,外层处于物理外网环境下,也称为外部服务,内外通过 API 网关连接。

  内部服务:鉴权服务、配置服务、图像识别服务属于内部服务,通常内部服务之间是相互信任的,但在安全要求较高的场景下,内部服务也不能互信。

  外部服务:桌面 APP、无线、第三方应用属于外部服务,外部服务分为两种类型:一种是 IBCS 的一部分,如 APP、H5 这些前端应用;另一种是 IBCS 之外的第三方应用。两种类型的授权方式是不一样的,前者一般采用 OAuth2.0 的密码模式,后者则采用客户端模式。

  其中密码模式常用于外部服务的鉴权,客户端模式常用于内部服务鉴权和开放平台应用的授权,授权码模式常用于社会化登录和 SSO,因此 OAuth2.0 可作为完整的统一身份认证和授权方案。

  客户端 Client:一般指第三方应用程序,例如用 QQ 登录豆瓣网站,这里的豆瓣网就是 Client;但在微服务体系里,Client 通常是服务本身,如 APP 端的注册登录服务;

  资源所有者 Resource Owner:一般指用户,例如用 QQ 登录豆瓣网站,这里的所有者便是用户;但在微服务体系里,资源所有者是服务提供者本身;

  资源服务器 Resource Server:一般指资源所有者授权存放用户资源的服务器,例如用 QQ 登录豆瓣网站,这里的 QQ 就是资源服务器;但在微服务体系里,服务提供者本身便是资源服务器;

  授权服务器 Authorization Server:一般是指服务提供商的授权服务,例如用 QQ 登录豆瓣网站,这里的 QQ 便是授权服务器;类似地,在微服务体系里,鉴权服务便是授权服务器。

  其中,注册接口、SignUp-Page 和 Login-Page 页面是非受控接口/页面,意味着无须鉴权即可访问。

  SignUp-Page 和 Login-Page 页面是由 UIMS 提供的统一的注册和登录页面,当外部服务发起注册或登录请求时,有两种作法:一是统一跳转到 UIMS 的注册或登录页面,用户完成操作后调用 UIMS 的注册和登录 API 完成请求;二是在自己的注册和登录页面完成操作,然后以用户名和密码作为参数调用 UIMS 的注册和登录 API 完成请求。推荐采用第一种方法,类似于全网通行证,用户体验统一,不用重复开发注册登录页面。

  第一步:申请成为开发者。开发者分为个人开发者和组织开发者两类,实名认证也分两种类型进行。成为开发者的前提是成为平台的注册用户;

  第二步:创建应用,平台审核通过后,生成 AppId 和 AppSecret 给到开发者,每个应用对应一对 AppId 和 AppSecret。值得注意的是,每个 AppID 与用户账号是绑定的,因此每个 AppId 获取资源和能力的权限受到该用户账户权限的限制,典型的例子是对象存储服务(OSS/OBS);

  第三步:获取 Access Token,开发者按照 OAuth2.0 的规范,采用客户端(client_credentials)模式,利用申请到的 AppId 和 AppSecret 向 IBCS 申请 token;

  第三步:使用 Access Token 与平台进行交互,每次调用受控 API 时都携带此 token。

  一般来说,应当独立建设一个开放平台,开发平台作为整个云平台的一个子系统,同样依赖于 UIMS。在开放平台上,应当提供一套完善的界面和流程,以引导用户完成开发者认证和第三方应用接入的所有工作。此外,在前期阶段,也可以采用线下申请的方式,由管理员人工审核,在后台手动录入。

  在开放平台上,创建第三方应用的流程和步骤,与上一步骤『成为开发者,获取 IBCS 的能力集』一致。所不同的是,上个步骤是获取 IBCS 的能力,而本步骤『创建第三方应用』,是基于开放平台开发应用,类似于微信小程序。

  应该允许开发者将异构系统(第三方应用)接入 IBCS,以增强 IBCS 的能力。例如,假设 IBCS 本身不具备识别特种汽车的能力,但允许接入其他开发者开发的基于图像的特种汽车识别应用。

  第三方应用接入,归属于开放平台的范畴。接入的流程和步骤,与第三步骤『成为开发者,获取 IBCS 的能力集』一致,由开放平台提供标准的 API,第三方按照接入规范执行。

  例如,用户通过 APP 登录 IBCS 后,访问图像识别服务的过程:用户登录后获得 token,由 APP 携带此 token 向图像识别服务发起请求,图像识别服务首先调用鉴权服务验证 APP 的身份(通过 ClientId 和 ClientSecret),然后再验证用户的身份(通过 token),如果 APP 和用户都获得授权,则请求通过,返回识别结果。

  浏览器的同源策略给 Web 应用划定了安全边界,是 Web 应用安全模型的重要基础。基于令牌的安全系统,在同源策略的约束下面临两个问题:

  第一个问题,一般采用 CORS 方案,在服务端的响应头声明 Access-Control-Allow-Origin 参数即可解决跨域请求的问题。

  第二个问题,在同域环境下,传统方法是采用 Cookie 的方案。跨域环境下,也有几种方案,从安全性和简便性考虑,推荐采用这种方案:

  将需要 SSO 状态保持的应用归到同域 SSO 应用中,将其他应用归到跨域 SSO 应用中;

  对于同域 SSO 应用,一般是企业内部应用,或相关性较高的应用,这些应用的域名采用相同的父级域名,继续使用 Cookie 方案;

  对于跨域 SSO 应用,不提供 SSO 状态保持。当用户首次打开此类应用时,由于 Cookie 无法跨域,因此服务端无法感知用户的登录状态,此时用户是处于未登录状态的;当用户访问受控页面或点击登录页面时,须重新执行登录操作。

  OAuth2.0 是集中式的令牌安全系统,可以通过撤销令牌登出系统。关闭账户与此类似。

  可在鉴权服务或 API 网关增加规则过滤器,将商业授权策略应用到授权规则中。

  JWT 是一种自包含的客户端令牌系统技术规范,这是其与 OAuth2.0 最大的不同。除此之外,可以简单地将 JWT 当作 OAuth2.0 密码模式的半自动版本。在实施 JWT 方案时,大部分情况下与 OAuth2.0 基本一致,本文不重复阐述,只对几个要点和不同之处加以说明。

  由于 JWT 属于自包含的客户端令牌系统,令牌发出后无须服务器验证,只需在客户端验证。客户端验证并解签后将得到必要的信息,例如用户基本信息和权限标识符。这种设计天然地存在无法撤销令牌的问题。解决方案是在 API 网关对 JWT 进行拦截,这里有多种方法:

  令牌撤销由 UIMS 发出,经由消息队列、API 等手段通知到网关,网关维护一个已撤销令牌的黑名单,对所有经过网关的 JWT 进行比对,TRUE 则拒绝转发,并返回 401;

  令牌撤销由 UIMS 执行后,网关每次收到 JWT 请求时,查询令牌数据库(如 Redis),比对该令牌是否已经撤销,如已撤销则返回 401。

  非对称算法的重要特点是,使用密钥加密时,必须用公钥解密;用公钥加密时,必须用密钥解密。利用此特性,通常在服务端采用密钥加密信息,然后客户端采用公钥解密信息。由于密钥存储在服务端,因此安全性高;公钥本身可以公开,因此可以在客户端存储。

  JWT 经由服务端用密钥加密后,发往客户端,客户端使用公钥进行解密,便得到了 JWT 的明文。JWT 包含了丰富的信息(通常是用户基本信息和权限标识符),只要解密成功,客户端完全可以信任此 JWT,因此不必再依赖于服务端重复鉴权。

  以 IBCS 为例,当图像识别服务服务携带 JWT 向配置服务请求资源时,配置服务使用公钥解密,只要解密成功,配置服务完全可以信任图像识别服务,因此也不必再依赖于鉴权服务的重复鉴权。对于安全性要求不高的场景,也可以使用 HTTP Basic 验证进行简单鉴权。

  同样,当外部的 APP 携带 JWT 向内网的图像识别服务发起请求时,图像识别服务使用公钥解密,只要解密成功,图像识别服务完全可以信任该 APP,有所不同的是,外部服务向内网服务发起请求,必须经过 API 网关,由网关执行规则过滤,确保 JWT 是仍处于有效状态。

  本文给出了微服务架构下的统一身份认证和授权的设计方案,从平台级 SAAS 模式下『统一身份治理』的概念出发,梳理了关键的需求点,提出了对应的解决方案。其中 OAuth2.0 是最佳解决方案,不过在实际运用中,应当遵循『合适原则』、『简单原则』和『演化原则』三个原则,不能盲目照搬。

  从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化,身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用,如何保证高效安全的...博文来自:Stars永恒的博客

  通过nginx反向代理,使多项目可以共享微信授权登陆首先是反向代理的配置在nginx的配置文件中upstreamweb{#这个web1和下面的端口是自定义的,内网ip可以通过ifconfig查看ser...博文来自:weixin_34319999的博客

  转自:先说下背景,项目包含一个管理系统(web)和门户网站(web),还有一个手机APP(包括An...博文来自:穿拖鞋写程序

  本节讲权限认证,也就是授权基于角色的访问控制和基于权限的访问控制的小实例以及注解式授权和JSP标签授权详解权限认证权限认证核心要素权限认证,也就是访问控制,即在应用中控制谁能访问哪些资源在权限认证中,...博文来自:谙忆-陈浩翔

  前言说明一下需求,最近做的平台,有多张用户表,怎么根据不同用户登录去执行自己查询不同数据库并实现认证的业务逻辑呢?博主参与的产品开发进入阶段性完成期,有时间将过程中遇到的相关问题一一总结。总结实现本需...博文来自:visket2008的专栏

  [TOC]更新记录客户端集成示例2017-12-28项目起源:公司随着业务的增长,各业务进行水平扩展面临拆分;随着业务的拆分各种管理系统扑面而来,为了方便权限统一管理,不得不自己开发或使用分布式权限管...博文来自:weixin_33800463的博客

  在微服务架构中,统一认证与授权是非常基础的功能服务。在过去的单体应用中,可以基于Session实现基本的登录与鉴权。在微服务时代,基于服务自治的原则,每一个微服务实例都能够对外提供服务,Session...博文来自:GitChat

  深入聊聊微服务架构的身份认证问题昨天晚上学习了“聊聊架构”组织的技术分享,做了一点总结如下:微服务架构下的身份认证与鉴权.png......博文来自:weixin_34023863的博客

  授权码类型介绍授权码类型(authorizationcode)通过重定向的方式让资源所有者直接与授权服务器进行交互来进行授权,避免了资源所有者信息泄漏给客户端,是功能最完整、流程最严密的授权类型,但是...博文来自:yunzhaji3762的博客

  shiro实现APP、web统一登录认证和权限管理先说下背景,项目包含一个管理系统(web)和门户网站(web),还有一个手机APP(包括Android和IOS),三个系统共用一个后端,在后端使用sh...博文来自:weixin_43845335的博客

  ApacheShiro是一个强大而灵活的开源安全框架,从官网上,我们基本上可以了解到,她提供的服务非常明确:1.Authentication(认证)2.Authorization(授权)3.Sessi...博文来自:小生的博客

  下面来说一下Shiro的认证。如何来做Shiro的认证呢?首先回顾一下之前剖析的Shiro的HelloWorld程序中有关认证的部分代码://获取当前的SubjectSubjectcurrentUse...博文来自:程序猿之洞

  这篇文章是微服务化改造系列的第四篇,主题是授权中心。有了服务注册中心和配置中心,下一步应该就可以发起服务调用了吧?Wait,还有一个关键问题要解决。不同于单体应用内部的方法调用,服务调用存在一个服务授...博文来自:Hello, Im eMac

  【前言】在上篇博文中小编为大家分享了《SCPPO:系统统一身份认证的改造之路》,由于篇幅原因其中一些东西只是简单提了一下,也有部分内容没有说出来;今天小编继续接着上篇的博文,一方面为大家解上次的闷儿,...博文来自:通往精英的成长之路

  现在系统一般采用sso架构,统一接入登录,有比较出名的开源框架CAS,对于各种语言都做了单点登录接入的支持,当然你也可以有自己的登录认证接口,然后在代码里面实现登录认证就好了。。。为什么我要写这篇文章...博文来自:炫律的博客

  shiro实现APP保持登录状态,以及web统一登录认证和权限管理,会话保持在web和APP之间。转载:博文来自:小倪子

  cas单点登录架构的形成,理解,实践是个过程,整个实现有一定的复杂,网上的基本架构图如下:但在实施的时候,并不一定各项技术都需要用到,比如,我的实施整理了一下,是以下改进和简化的架构: 1.通过LDA...博文来自:LinBSoft的专栏

  引言      最近一直在思考微服务架构下的最佳授权方式,于是JWT便出现在了我的视野中,通过对其原理的学习及在项目中的实践我想这便是我想要的答案,本文将阐述JWT背景原理,以及提及我在开发系统过程中...博文来自:Buynow_Zhao的博客

  【事件背景】洋葱服务为什么没被成功接盘?_搜狐科技_搜狐网今天无意中看到这则新闻,发现人家洋葱认证服务已经停运1年多啦,瞬...博文来自:Enweitech Software Works

  【前言】小编最近做的项目主要工作是维护,项目基本功能已经实现,平常时修改一些Bug或根据需求做些新的功能,不过这些新功能多多少和之前的功能有相似之处开发时可参考;最近组长给分了个特别新功能—统一身份认...博文来自:通往精英的成长之路

  基本原理用户通过前端页面登录成功后后端返回token字符串,前端将token存入localStorage中,之后前端所有的数据请求都携带token(token可以放在请求头或请求参数里,只要跟后端约定...博文来自:Caesars blog

  前言在一篇Springcloud微服务实战——基于OAUTH2.0统一认证授权的微服务基础架构中我提到用Nginx做资源服务器的负载均衡,其实这是有误导部分读者的,皆因我当时没有进行仔细的考究和研读代...博文来自:孤帆远影碧空尽

  关于openid写道OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站,用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是,他们只需要预先在一个作为OpenID身份提供...博文来自:麻烦处...

  11月16日,数人云在PaaSInnovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企...博文来自:shurenyun的博客

  微服务的两套认证:1.身份认证在zuul加filter拦截获取请求usertoken,校验usertoken合法性2.服务认证为内部服务之间通过servertoken来校验服务调用的合法性整个流程的大...博文来自:程序和音乐一样,都是一门艺术

  找到一个视频教程,还不错,适合入门和初学者。博文来自:Code Captain的专栏

  Istio0.8版本增强了服务间双向认证,1.0版本增加了终端用户认证的功能,这样整个服务网格的认证策略就齐全了;目前只支持JWTAuthentication,可以使用authenticationpo...博文来自:陈振阳

  微服务架构下的统一异常处理本文简单串联Java异常的基础知识和结合项目实践分享相关知识。...博文来自:xiaoman的博客

  参考:这里有2个ssoclient工程,代码一样,只是端口不一样。一个端口为8080,...博文来自:Donny的专栏

  微服务的日志分散在多个机器上,不便于问题定位博文来自:nanxiaotao的博客

  平台级SAAS架构的基础-统一身份管理系统.html[TOC]业内在用户统一身份认证及授权管理领域,主要关注4个方面:集中账号管理(Account)、集中认证管理(...博文来自:azhuyangjun的博客

  如下图是公司的统一登录界面:众多子系统的登录页面不再使用,所有登录走统一登录页面,登录时选择你要登录的系统,这里以我改造的安全管理系统为例。在安全管理系统项目中加入一个整合的jar包,其实就是一个拦截...博文来自:itbigboy的博客

  发展史和背景从单体应用架构到分布式应用架构再到微服务架构,应用的架构通过不停的改进升级的方式满足不断扩大的业务需求。随着应用架构的改变,身份认证的方式也在发生变化,为了适应架构的变化、需求的变化,身份...博文来自:weixin_33778544的博客

  夜行侠老师录制的:SpringCloud微服务架构在互联网中应用 由大象分享网出版:第1节、Springcloud介绍第2节、Eureka的使用第3节、Eureka集群第4节、restful请求第5节...博文来自:shiqu9950的博客

  这篇文章讲述了如何简单地使用SpringCloudGateway,来源于SpringCloud官方案例,地址一、简介gatewa...博文来自:疯狂的蜗牛

  wqffighting:你好,请问这种代码(类似滚动条可以滑动)是如何实现的?谢谢你了。

http://e-ndicus.com/gongyuegoujia/1026.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有