精华内容
下载资源
问答
  • 一致和统一的区别
    千次阅读
    2022-02-07 00:17:43

    关于各种一致性的理解:
    1、数据一致性,往往指的是缓存和数据库的一致性。

    2、事务的一致性,和原子性类似,都是从一个状态变到另一个状态,但不同的是,原子性追求这个过程不能出错,不论结果对不对,不能出错。但一致性更追求结果一致,比如A减少100,B增加100,这是一致的。当A减少100,B增加60,这是原子的,但不是一致的。

    3、分布式事务的一致性:本质上来说,分布式事务就是为了保证在分布式场景下,数据操作的正确执行。但分布式事务不像本地事务,可以做到ACID,分布式事务做不到。比如分布式存储场景下,一个存储节点通过本地事务减少100,不能同时保证另一个存储节点事务增加100,这实际上就是数据不一致。而在本地事务中,是可以做到的,本地事务把减100和加100当作一个原子操作来执行。
    但是分布式事务也是可以解决这一类问题的,但从而带来了很高的代价,也就是我们说的CAP理论,P分区容错是一定的。那么当C很强时,也就是强一致性的时候,也就是说用户访问任何一台数据库服务器,必须都是要数据一致的,第一个存储节点减少100,另一个存储节点必须增加100,这就是强一致性,但是问题是有网络延迟,第一个节点减少了100,第二个还没来得及加100,此时用户要访问第二台数据库服务器,怎么办? 那就不让他访问,也就是吸收Availability可用性。那如果要保证可用性怎么办?那就牺牲一致性,数据不一致没关系,最终一致就可以了。

    那解决这样的问题的框架有哪些?比如seata的AT,TCC等,就是实现全局事务的统一提交,要么就不提交,那这样就能保证所有数据的一致了。但当全局事务没有统一提交的时候,可能用户的请求查数据库,可能查到的还是旧数据。

    4、分布式事务的原子性:单个分枝事务成功,但其他事务可能失败,需要全局回滚。

    5、注意:CAP理论强调的是说在分布式存储系统中的。

    以上纯属个人理解,有问题请指出探讨。

    参考:https://blog.csdn.net/yeyazhishang/article/details/80758354
    参考:https://segmentfault.com/a/1190000040321750
    参考:http://www.dockone.io/article/9804

    更多相关内容
  • 一致性成本vs非一致性成本,原文...一致性成本(cost of conformance),该成本是预防性的,在缺陷发生之前付出的,用于质量与要求或规范一致而付出的成本。 非一致性成本: 非一致性成本(cost of non-conformance..

    一致性成本vs非一致性成本,原文链接:https://www.ffeeii.com/1882.html

    质量成本:

    质量成本(cost of quality)包括在产品生命周期中为预防不符合要求,为评估产品或服务是否符合要求,以及因未达到要求(返工),而发生的所有成本。

    一致性成本:

    一致性成本(cost of conformance),该成本是预防性的,在缺陷发生之前付出的,用于质量与要求或规范一致而付出的成本。

    非一致性成本:

    非一致性成本(cost of non-conformance),是由于质量与要求或者规范不一致而造成的成本。

    一致性成本和非一致性成本对比:

    一致性成本和非一致性成本对比

    举例:

    1、为了确保满足质量标准,项目经理聘请外部资源来检查可交付成果的质量。这种检查的成本可以分为哪些成本类别?

    • A:预防成本
    • B:评估成本
    • C:外部成本
    • D:失败成本

    答案:B。检查属于评估成本

    2、下面是非一致成本的例子,除了:

    • A:返工
    • B:培训
    • C:报废
    • D:保修

    答案:B。解析:培训是为了提高团队成员的能力或统一对项目的质量的认识,是为了预防缺陷的产生,是一致性成本。

    展开全文
  • 当你的问题思考提升一个层次,从前端框架设计角度思考的时候,会不会思考这样的问题:对于交互样式比较固定的业务系统,能否基于UI一致性、UI设计规范进行规范的交互方式、页面及组件样式设计,简易高效的进行界面...


    一、前言

    做前端开发一段时间后,你会不会发现自己在持续的做着页面重复开发的工作,后面甚至干脆是Ctrl+CCtrl+V操作。你可能会说,那就使用组件啊!的确,通过抽取公用视图,创建子组件的方式确实可以提升代码复用度。上面是回答是基于你做程序员开发某个产品模块功能点的时候做出的。当你的问题思考提升一个层次,从前端框架设计角度思考的时候,会不会思考这样的问题:对于交互样式比较固定的业务系统,能否基于UI一致性、UI设计规范进行规范的交互方式、页面及组件样式设计,简易高效的进行界面搭建?通过搭建可视化、所见即所得的Web APP代码自动化生成平台降低前端开发的学习成本和门槛应如何设计?如何应用以上特性最大化实现产品UI一致性,提升用户体验?

    基于此,自己阅读了大量的文献资料,例如,美团的“乐高”、阿里的“飞冰”等,并以此探究如何最优实现前端产品开发的持续性,提升用户体验。

    二、痛点

    为满足业务层面的快速发展,在开发过程中由于UI缺乏标准,设计层面缺乏标准化的规范约束,UI设计风格不统一,导致的用户体验不佳问题不断凸显,很难去落实统一的设计规范,具体体现在以下4个层面:

    • 设计层面:由于UI缺乏标准化设计规范,在不同Web App及不同开发语言平台上设计风格不统一,导致用户体验不一致;设计资源与代码均缺乏统一管理手段,无法实现知识积累沉淀,无法适应新业务的快速开发需求。

    • 开发层面:组件代码碎片化,存在重复开发的情况,产出质量难以保证;由于各端代码API不统一,维护拓展成本较高,变更主题、适配Dark Mode等需求难以实现。

    • 测试层面:重复走查,频繁回归,每次版本出库均需验证组件质量。

    • 产品层面:版本迭代效率低,版本需求吞吐量低,不具备业务的快速拓展能力。

    为改善用户端体验的一致性,提升多技术方案间组件的通用性和复用率,降低整体视觉改版带来的研发成本,需要PM/UI/RD共同维护一套设计规范,在产品上统一风格,在源头上统一设计,在代码中统一实现。

    基于上述开发工作中的切实痛点,以及未来可预见的Web端能力需求,迫切需要一套统一的UI设计规范,以此沉淀设计风格,建立统一的UI设计标准。

    通过抽离成熟的业务场景,建立可提供高质量、可扩展、可统一配置的基于ElementUIiViewAnt-design-vue等主流UI样式库的组件代码库,使之具备支持多业务高层次的代码复用能力,进而提高UI业务中台能力,使项目保持高度一致性。

    UI一致性是绝大部分研发团队面临的共性问题,大家对落地设计规范,提高UI中台能力,提升产研效率具有强烈的诉求。通过UI一致性的建设,不仅可以在品牌上实现体验升级,更可以全面提高产研效率,为业务的快速迭代提供有力支持和有效保障。

    统一的品牌符号、品牌特征,有助于加深产品在用户心目中的印象。统一的用户界面和交互形式,能帮助用户加深对产品的熟悉感和信任感。而一个好的设计语言可以在体验上为产品加分,也能够更好的创造一致性体验。

    为了帮助更多的业务模块定制符合一致性原则的专属设计风格,可在实践中不断总结经验,开发一套通用的UI一致性解决方案。通过UI一致性工具链落地项目建设,并打造一整套的闭环UI开发流程。

    三、方案全景

    美团外卖UI一致性套件由积木工具链代码组件库定制化设计云协作平台以及文档化说明(官网)四部分组成。

    • 积木工具链:通过建立包含相同设计元素的统一物料市场PM通过Axure插件拾取物料市场中的组件产出原型稿;UI/UE通过Sketch插件落地物料市场中的设计规范,产出符合要求的设计稿。未来,希望通过高保真原型输出,可以给中后台项目、非依赖体验项目提供更好的服务体验,赋予产品同学直接向技术侧输出原型稿的能力。

    • 代码组件库ElementUIiViewAnt-design-vue):设计稿中的组件与RD代码仓库中组件一一对应。

    • 定制化设计云协作平台:与美团内部的印迹团队(云协作平台)合作开发,在RD的设计稿中标注了哪些是代码组件库中已有的元素,避免重复开发,同时关联了官网中该组件的使用说明,是代码组件库与官网的纽带。

    • 文档化说明:官网详细描述了代码组件库的集成方式、组件的使用方法,降低开发上手难度,只需要理解接口和职责即可进行业务开发。

    3.1 拓展阅读 什么是UI/UE设计?

    3.1.1 什么是 UE 设计?

    UE设计一般指游戏设计或游戏相关设计,还有网站的ue设计,其实就是UserExperience的缩写。是指用户访问一个网站或者使用一个产品时的全部体验。他们的印象和感觉,是否成功,是否享受,是否还想再来/使用,他们能够忍受的问题,疑惑和BUG的程度。

    UE是一种纯主观的在用户使用一个产品(服务)的过程中建立起来的心理感受。因为它是纯主观的,就带有一定的不确定因素。个体差异也决定了每个用户的真实体验是无法通过其他途径来完全模拟或再现的。但是对于一个界定明确的用户群体来讲,其用户体验的共性是能够经由良好设计的实验来认识到。

    而UE设计就是指设计人和产品或服务互动的一种机制,以用户体验为基础进行的人机交互设计时要考虑用户的背景、使用经验以及在操作过程中的感受,从而设计符合最终用户的产品,使得最终用户在使用产品时愉悦、符合自己的逻辑、有效完成并且是高效使用产品。交互设计的目的是使产品让用户能简单使用。任何产品功能的实现都是通过人和机器的交互来完成的。因此,人的因素应作为设计的核心被体现出来。

    3.1.2 UI 设计是什么?

    ui的全称是:UserInterface即用户界面,是指对软件的人机交互、操作逻辑、界面美观的整体设计。很多同学不知道ui是什么,以为画个ICON图标就是做ui了,导致很多人都忙着画各种各样的图标,这样很容易让那些新人们走错路。

    软件设计可分为两个部分:编码设计与UI设计。编码设计大家都很熟悉,但是UI设计还是一个很陌生的词,即使一些专门从事网站与多媒体设计的人也不完全理解UI的意思。UI的本意是用户界面,是英文User和interface的缩写。从字面上看是用户与界面2个组成部分,但实际上还包括用户与界面之间的交互关系。

    界面设计。在漫长的软件发展中,界面设计工作一直没有被重视起来。做界面设计的人也被贬义的称为“美工”。其实软件界面设计就像工业产品中的工业造型设计一样,是产品的重要买点。一个友好美观的界面会给人带来舒适的视觉享受,拉近人与电脑的距离,为商家创造卖点。界面设计不是单纯的美术绘画,他需要定位使用者、使用环境、使用方式并且为最终用户而设计,是纯粹的科学性的艺术设计。

    3.1.3 UE 与 UI 的区别

    简单的说UE多一个动效,UI就是图标。UE和UI在一定程度上是有所不同的,UI重视的是为用户提供良好的感官,而UE重视的是对用户行为的引导。两者应该是互相包含,互相影响。

    UI是使用界面,UE是使用感受,就拿京东和中国亚马逊来说,UI设计各有千秋,但是按照中国人的使用习惯京东的UE感觉更好,或许外国人的使用感受亚马逊更好,UI是客观的UE较为主观。在产品开发中,尤其是手机或者网站的开发过程中,最关键的是UI和UE。UE是用户体验设计师,UI是视觉设计师。通俗点讲,用户体验设计师就是管产品好不好用,是不是人性化。视觉设计师就是产品的美观。

    在图形界面产生之前,长期以来UI设计师就是指交互设计师。交互设计师的工作内容就是设计软件的操作流程,树状结构,软件的结构与操作规范(spec)等。一个软件产品在编码之前需要做的就是交互设计,并且确立交互模型,交互规范。

    四、UI一致性协作闭环流程

    1. 设计师逐步将设计语言沉淀为设计规范(包括组件、颜色、字体、图片等)上传至仓库供整个设计团队查阅,同时将其量化并内置于积木Sketch插件中;开发工程师负责将其代码化,针对ElementUIiVIewAnd-design-vue等主流UI框架进行组件库开发。

    2. 设计师使用积木Sketch插件绘制设计稿,可以保证设计元素均从既定的设计标准中获取,产出符合业务设计规范的设计稿,而代码组件库中也有对应的实现。

    3. 绘制完成的设计稿上传至协作平台,交付开发工程师进行设计稿还原。

    4. 开发工程师拿到设计稿后,就可以知道本次需求哪些组件已内置于代码组件库中,并可以点击设计稿中的链接,直接查看组件的使用说明。

    虽然UI一致性落地会增加开发工程师一定的工作量,推进一致性建设也是一个艰难的工作,且由于成本较高,无法量化评估收益,但一旦有效运作起来后,团队将获得丰厚的回报。UI一致性的建设需要设计者对现有状态有足够的认识,对业务有充分理解,以及优秀的设计能力,同时还要不断地进行实践和优化。为了保证一致性项目的成功落地,避免“半途而废”,可通过制定一系列的推进措施来提高执行力与产出质量:

    1. 项目小组不能脱离日常需求开发工作。这样可以保证设计师所沉淀的设计元素始终来自于最新的业务场景,同时项目产出可以快速应用到最新的版本中得以验证。

    2. 优先选择受视觉因素影响较大、投入产出比高的模块场景进行改造,化繁为简,确定最小验证闭环 (MVP,Minimum Viable Product),在实践中不断优化,进而跑通整个流程。

    3. 项目推进由UI同学按版本提出需求,业务端排期并落地实施,由UI统一验收。

    4. 建立阶段性目标,并完成指定的具体工作规划,定期复盘完成情况,保证项目的持续推进。

    细化来看,UI一致性整体方案主要分为两个部分,一个是设计体系建设,另一个则是工具链建设。设计体系建设是基础,主要是设计师沉淀设计风格,建立统一的UI设计标准,而工具链建设则是支撑,是开发人员通过开发一系列的工具将开发过程闭环,实现设计体系落地。

    在长期的版本迭代中,随着功能的不断增加以及UI的持续改版,新旧样式混杂,维护极为困难。设计师通过将页面走查结果归纳梳理,制定设计规范,从而选取复用性高的组件进行组件库搭建

    通过搭建组件库可以进行规范控制,避免控件的随意组合,减少页面之间的差异;

    组件库中组件既能满足业务特色,同时也可以应对不断变化的业务环境,具有云端动态调整能力,可以在规范更新时进行统一调整。

    在不影响需求实现以及设计效果的前提下,只有在方案设计中尽可能使用组件,提升组件覆盖度,才可能真正通过组件库来提效。而除了在新的需求中使用组件,还需要将已有页面内容尽量替换成组件,才能避免页面升级时的重复修改问题,真正提高产研效率。在进行组件库建设时要注意以下几点。

    • 选择合适粒度

    组件的粒度曾是困扰设计师与开发工程师很久的一个问题,虽然有构建设计系统的核心理论——原子设计理论为指导,即按照“原子、分子、组织、模板、页面”五个层面进行页面设计。这一理论对于从零开发新应用没有任何问题,但进行一致性改造的Web App,往往会暴露出很多设计问题,对于已经存在数百个成熟的线上页面,改造存在非常大的困难,必须根据具体业务选择合适粒度。在进行组件制作前,项目开发工程师需要对已有页面进行梳理,对使用到的组件进行分类,并根据组件的使用频率进行排序,制定逐步替换计划。从而避免组件库虽然做的很全、花费了大量人力,但实际很多组件都用不上,或者开发的组件过少,覆盖场景不足等问题。

    通过将走查结果与设计师反复交流,会发现复用性较高的组件大体可以分为两类:第一类“基础控件”,也就是类似于标签、按钮、开关、弹窗等具备基础功能的元素,对应原子理论中的原子;第二类“业务组件”,类似于商品卡片等,是由“基础控件”组成(比如商品卡片由“标签控件”与“图片控件”组成),同时“业务组件”还能相互组合,成为更高阶的“复杂组件”,类似于原子理论中的分子。“业务组件”的组合又是千变万化,不同样式的业务组件可以组成类似“商家列表”、“菜品列表”等“模板”,而“模板”与“基本控件”组合在一起,就成为了“页面”。

    • 具备拓展性

    组件必须具备一定的可配置属性才能提升适用场景覆盖度。可配置属性体现在三个方面:组件支持局部元素展示隐藏,例如商品卡片的标题、说明、价格可根据接口数据控制展示逻辑;组件支持多种样式,例如商品卡片的左图右文排列、上图下文排列;组件支持业务方配置主题,如调整高亮色、调整对齐方式等。

    • 支持统一管理

    组件管理功能对UI一致性起着至关重要的作用,这主要体现在两方面:首先是设计风格沉淀,通过形成自己的独特风格,设计团队根据设计规范,对符合UI一致性业务场景的组件不断进行抽象及建设,沉淀出越来越多的通用业务组件,这些组件需要及时扩充到Library中,供团队成员使用;另外一个作用则是保持团队使用的组件均为最新组件。由于各种原因,组件的设计元素(色彩、字体、圆角等属性)可能会发生变更,需要及时提醒团队成员更新组件,从而保持所有页面的一致性。

    UI设计语言与自身业务关联性很强,很多业务模块都有一套自己的设计系统。“通用”通常意味着无法满足具有业务特色的需求,不同业务的组件、色彩系统、动效、字体样式等千差万别,其中任意一环的缺失都会导致UI一致性被破坏。

    设计语言并不是一个抽象的概念,例如,大家提到美团就想起美团黄,提到阿里就想起阿里橙、提到京东就想起京东红等,通过设计语言可以传达品牌主张和设计理念。同一板块产品必须形成一套属于自己的独特风格,对于一致性元素处理有一套自己的标准,对于产品的设计者而言,必须将这种风格化延续,才能使我们整个项目具备高度的一致性,才能保持“产品特色“,保证吸引力。

    以插图为例,插图作为一种视觉语言,是品牌识别度的关键核心元素,与单纯的文案信息不同,图形化在直观描述固有信息的同时,也在塑造情感背景,使用户更具沉浸感和共情性。插画在提升产品用户体验的同时完成商业目标,在表达效果及生产效率上有独特的优势,在追求效率的互联网产品中被大量地运用。

    由于之前产品中的插图未经系统整合,而插画师的个人风格明显,不同的设计师在图形化的工作协同中,风格很难复现,而单纯由一名设计师去完成整体业务的插画建设工作也存在一定风险。不同设计师之前画过的元素无法互通,造成很多元素重复设计、风格不统一,缺乏系统性地创作和整理,无法最大化地提升生产效率,并且影响产品的品质感。所以插图体系在保持品牌一致性、提升工作效率以及规避风险上尤为重要。

    Iconfont可译为图标字体,顾名思义就是用字体文件取代图片文件来展示图标、特殊字体等元素的一种方法,不仅具有矢量性、可自由变化大小的特点,而且支持任意改变颜色。。简单来说,Iconfont就是把多个图标文件打包为ttf字体文件,注册到系统中,Web App可以像使用字体一样使用图标。其原理可以简单理解为通过ttf字体文件维护一个Unicode码与图形的映射关系。当使用Iconfont为项目助力的时候,配置多个图标不再需要去下载数个PNG文件,仅需要维护一套ttf字体文件即可。

    Web App发展到一定阶段,必然面临着包体积会越来越大,无用图片与相似图片也会越来越多的问题。同时,由于开拓新业务而不断涌现的新场景,又不可避免地新增大量的图片。总结来看,图片文件在一致性项目中需要解决两个问题,即存量图片的处理以及新增图片的管理。

    对于存量图片,必须判断其合理性,项目中存在大量相似图片,这些图片可能仅是padding不同,或者颜色尺寸存在微小差异,可以通过脚本扫描相似图片,根据图片的特征Hash判断图片的相似度,相似度高的图片根据UI建议,保留一张即可。那如何防止新增图片“重蹈覆辙”呢?通过建立图片管理后台,将图片按场景分类,标准图片需从组件代码库中选取,新增图片执行PR策略,需相关负责人审核,可有效防止相似图片的堆积问题。

    动效是指那些能够为产品赋予生机的动态界面元素及视觉效果,这些交互效果通常与特定的响应行为相关,甚至包括那些与交互行为没有直接关联的临时状态。

    精细而恰当的动画效果可以传达状态,增强用户对于直接操纵的感知,通过视觉化的方式向用户呈现操作结果。

    随着业务需求的不断增加,动效的使用比重在不断增加,重要性日渐凸显,也是增强用户体验与竞品拉开差距的重要因素,因此,统一规范的使用动效尤为重要。通过动效库建设,UI层面可以承载品牌、传递情感,加深用户对Web App的印象,让用户放松、愉悦;RD层面同一组件可在多场景直接复用,还降低了研发成本。

    颜色可以起到传递品牌信息、区分信息的所属关系、标明控件的选中状态以及对内容的信息进行分层级展示等功能。重要的信息需要在页面中被突出展示。系统级色彩体系主要定义了应用的主要颜色、文字颜色、辅助颜色以及标准渐变色,颜色在一定时期内建议不再支持新增。通过将标准色板内置于插件中,限制UI绘制设计稿时的使用范围,而RD工程师仅可通过代码组件库中选取颜色,保证色值的准确性,也便于进行主题定制。

    字体是体系化界面设计中最基本的构成之一。用户通过文本来理解内容和完成工作,科学的字体系统将大大提升用户的阅读体验及工作效率。设计师在字体设计过程中需要关注非常多的方面,比如字体family、字距、行高、段落等等。如何让文字看起来更自然,是设计师团队一直探寻的答案,UI工程师根据文字的层级关系,指定了HeadlineSubtitleBodyButton以及Caption的文字使用规范,根据设计稿中文字的位置,就可确定文字的具体样式。

    在组件代码库时,应具有以下功能:

    • 提高项目可维护性

    由于组件库中的组件职责单一,降低了系统的耦合度,开发人员可以很容易地了解该组件提供的能力。组件可以自由替换、组合为高阶组件,在进行组件更新时仅需修改一处。每个项目成员维护一定数量的组件,让团队中每个人都能发挥所长,可以最大化团队的开发效率。

    • 实现文档化

    组件接口有统一的规范,降低新人的上手难度,新成员只需要理解接口和职责即可开发组件代码,由于代码的影响范围仅限于组件内部,对项目的风险控制也非常有帮助。通过对组件统一管理,实现代码的积累沉淀与有效复用,全面提升了新业务的需求开发效率。

    • 便于单元测试

    由于组件职责单一而清晰,对外仅暴露接口,概念上可以把组件当成一个函数,输入对应着输出,这让自动化测试变得更加简单。

    • 实现无障碍等定制化功能

    无障碍功能可以改善残障人士的用户体验,组件库中的组件资源高内聚,完全由自身控制加载,不与全局或其他组件产生影响。组件的加载、渲染路径清晰可控,对于组件功能定制,实现类似于无障碍等功能较为方便。

    目前,市面上耳熟能详的组件库包括阿里的Antd DesiginFusion Design以及美团的Roo Design等,基本都是服务于Web开发的组件库,通过这些组件库可以快速搭建一些中后台系统。

    为什么没有知名的Native开源组件库呢?因为每个应用的主题、风格以及交互体验都是不同的,而这些不同恰恰是传达品牌主张和设计理念的灵魂,因此必须结合业务,针对ElementUIiViewAnt-design-vue等主流UI样式库进行组件库开发。通过搭建全平台代码组件库,可以保证同一个UI组件在各端表现一致,进行UI升级时降低改错或遗漏的风险,除此之外,还能降低测试压力,提高需求的吞吐率。

    官网相当于项目的门面,一个好的门面才能吸引更多的用户,才能更好地对项目进行推广。官网作为设计师与开发工程师沟通的媒介,需要两者共同维护。通过官网可以帮助团队内设计师沉淀设计风格,建立统一的UI设计规范,帮助RD工程师进行组件文档管理与查阅。

    4.1 手册功能

    当前的官网应主要包括设计语言组件库插画库以及资源下载,分别服务于UIRD工程师。

    4.1.1 设计语言

    UI一致性项目采取“原子理论”的构成原理,即从最小的元素开始定义,进而将这些元素按照规则进行组装,拼接成组件,最后通过这些组件拼接成最终的页面,这是一个由点到面的过程。设计语言章节主要服务于UI/UE工程师,该章节通过视觉、设计模式、动效等三个子章节使得读者能够快速了解项目的设计规范,从而快速上手。

    4.1.2 组件库

    组件库是设计模式中各种元素的具体实现,在这个页面描述了组件的使用方式。

    4.1.3 插画库

    插画库中则介绍了插画的使用场景,插画的绘制规范以及插画案例展示。

    4.1.4 资源下载

    提供产品下载功能。

    4.2 方案设计

    由于官网以纯粹的图文展示为主,且迭代频率较快,因而选择当下较为普遍的文档-网站生成系统VuePress,只需按照一定规范将书写的Markdown文档放至相应目录,前端自动解析后生成导航,并且支持多语种、图片、文件、视频等素材。这种方式极大地缩短了官网的开发周期,即便是没有前端经验的同学也能快速上手。

    为了方便UI工程师对官网文档的修改,应基于文档网站生成系统搭建在线编辑平台。通过该平台,相关人员可以直接做到在线编辑、发布,节约了UI工程师RD工程师的沟通成本以及发布成本。填充期间,使用者可以实时预览编辑的内容,修改后只需点击保存即可立即更新到网站中。

    官网支持平台化功能,不同业务方可以创建属于自己的文档站点,一个好的文档站点对于设计组的方案推广、外部接入都大有裨益。

    4.3 工具链的闭环

    当我们信心满满的把UI一致性解决方案推广到日常开发中时,除了听到可以提升效率的褒奖外,开发同学对项目的吐槽声也常常传入我们的耳边,“怎么才能知道设计稿中的哪个组件已经开发完成了?”,“查询这个组件的使用方法好麻烦,每次都要去官网检索”,“规范颜色、图标的名称是什么?怎么才能引用到?…”

    我们无法限制别人的选择,所以只能让这套体系变得更好用,如果不去优化整个流程,将其串联起来形成闭环,后面整个项目可能都会慢慢崩塌,可以考虑将设计稿作为衔接RDUI的纽带,可以把官网与代码仓库打通。

    通过定制设计云协作平台,在给RD的设计稿中标注了哪些是代码组件库中已有的元素,避免了重复开发,同时关联了官网上该组件的使用说明,RD工程师在开发过程中遇到组件使用问题无需检索,点击即可跳转至使用文档,真正做到了一致性元素的全覆盖。

    五、拓展阅读

    展开全文
  • 统一用户认证单点登录授权的原理与流程

    万次阅读 多人点赞 2019-02-02 13:58:09
    彻底搞懂统一用户认证用户单点登录1. 前言2. 原理1. 统一用户认证介绍2. 单点登录原理介绍3. OAuth 2.0的统一用户认证1. OAuth 2.0协议流程简介2. 授权码模式3. 简化模式4. 密码模式5. 客户端模式6. 授权码模式...

    1 前言

    随着信息技术和网络技术的迅猛发展,大型企业内部的应用系统越来越多。比如在电商行业,常见的应用系统就有商品系统、订单系统、支付系统、物流系统、客服系统等等。这些系统互相独立,且每个系统都需要识别用户的身份,并根据用户的身份来进行权限控制。如果每个系统都各自实现用户管理和认证的功能,就会带来用户信息冗余、不同步等问题,也会导致用户必须记住每一个系统的用户名和密码,从而给用户带来不少麻烦。针对这些实际情况,统一用户认证、单点登录、授权等概念应运而生,而且被广泛应用到企业应用系统中。

    本文主要介绍基于Spring Security + OAuth 2.0协议的统一用户认证、单点登录、授权的原理和流程。

    2 介绍

    2.1 统一用户认证

    统一用户认证,就是判断一个用户是否为合法用户的过程。一般来说,大型企业内部的每个应用系统都需要识别用户的身份,如果每个系统都各自实现用户管理和认证的功能,那么对于企业而言,必定会增加用户信息的管理成本,也会导致多个系统之间的用户信息冗余且不同步的问题,对于用户而言,必须记住每个系统的账户信息,从而带来不便。例如,用户同时使用某个大型企业内部的10个应用系统,就必须在这10个应用系统中都创建自己的账户并记住账户,这样每个系统都需要管理用户的信息,而且一旦用户在某个系统中修改了信息,就会导致系统之间用户信息不一致的问题。万一系统的数量增加到50个、100个了?估计企业和用户都要疯了。

    解决上述问题的根本方法是建立统一用户管理系统(UUMS)。UUMS统一存储、维护、管理所有应用系统的用户信息,所有系统的用户认证功能全部由UUMS来完成,而用户权限控制功能则由各个应用系统自己完成。可见、UUMS应具备以下基本功能:

    1. 统一用户管理:用户信息的存储、维护、管理等功能。
    2. 统一用户认证:用户身份识别、角色分配等功能。

    统一用户认证是以UUMS为基础,对所有的系统提供统一的认证方式和认证策略,以识别用户身份的合法性。

    注意:统一用户认证是为了解决多个系统的用户管理和认证的问题。

    2.2 单点登录

    对于大型企业内部的多个应用系统而言,统一用户管理系统能够很好的解决用户信息冗余和不同步的问题,也能减轻用户需要创建并管理多个账户的痛苦,即使这样也仍然存在多个系统都需要用户登录的问题。例如,用户同时使用某个大型企业内部的10个应用系统,那么就需要用户使用同一个账号信息去分别登录每个系统,这样的操作必定会导致用户体验太差。单点登录就是为了解决这个问题而提出的。

    单点登录(Single Sign On,简称SSO)是一种方便用户访问多个系统的技术,用户只需在一个系统中进行登录,就可以在多个系统间自由穿梭,不必重复输入用户名和密码来确定身份。

    注意:单点登录是为了解决同一用户在使用多个系统时的重复登录的问题。

    2.3 授权

    我们经常会遇到这样一个问题:在访问某些系统(例如知乎、豆瓣),都需要用户先注册账号,然后登录才能继续访问,而很多用户却又嫌注册太麻烦,为了方便用户使用,这些系统都会提供使用第三方账号(例如微信账号)进行登录的方式。那么问题来了,如果用户直接将自己的第三方账号和密码告诉这些系统,那么又怎样确保这些系统不会泄露用户的账号信息以及私自获取用户在第三方系统中除用户账户之外的数据?“授权”就能很好的解决这个问题。

    所谓“授权”,就是用户先授予某个系统可以使用自己的第三方账号信息的权利,然后该系统就可以使用用户的授权到第三方去获取该用户的账号信息,而第三方验证了用户的授权之后就按照用户授权的范围把用户允许的账号信息返回给该系统,而不会把用户没有允许的数据返回给该系统。这样一来,用户既可以访问这些系统,又不需要把自己的第三方账号信息告诉给这些系统,从而可以解决上述问题。

    注意:授权是为了解决多个系统之间用户信息共享的问题。

    3 原理

    3.1 统一用户认证原理

    统一用户认证的原理相对简单,基本都是判断当前正在操作的用户的账户是否存在且密码是否匹配。如果用户认证通过了,那么用户就可以使用预先设定的角色来进行操作了,至于该角色能够进行哪些操作,则由各个应用系统自己指定了。统一用户认证包括以下几种认证方式,这些认证方式采用模块化设计,可以根据需求而组合使用:

    1. 匿名认证方式:用户不需要任何认证,可以匿名的方式登录系统。
    2. 用户名/密码认证:这是最基本的认证方式。
    3. PKI/CI数字证书认证:通过数字证书的方式认证用户的身份。
    4. IP地址认证:用户只能用指定的IP地址或IP地址段访问系统。
    5. 时间段认证:用户只能在指定的时间段访问系统。
    6. 访问次数认证:累计用户的访问次数,使用户的访问次数在一定的范围之内才可以访问系统。

    Spring Security和Shiro是两种主流的统一用户认证框架。

    3.2 单点登录原理

    单点登录的原理就是:用户在使用多个应用系统时,当用户第一次访问任一应用系统时,会因为没有登录而被引导到用户认证系统中进行认证,如果认证通过,用户就会得到一个认证凭据——ticket,用户再访问其它应用系统时,就会带上这个ticket作为自己已认证的凭据,而其它应用系统校验ticket通过之后,用户就可以不需要再次认证就可以直接该其它应用系统了。

    要实现单点登录,需要以下主要功能:

    1. 所有的应用系统共享一个用户认证系统:统一的认证系统是单点登录的前提之一。
    2. 所有的应用系统能够识别和提取ticket信息:应用系统应该能对ticket进行识别和提取,从而判断当前用户是否已经认证,从而完成单点登录的功能。

    单点登录的实现方案较多,有Spring Security + OAuth方案、Spring Security + CAS方案、Shiro + CAS方案,但Spring Security + OAuth方案更常用,本文讲解的单点登录也是基于这种方案。

    3.3 OAuth授权原理

    OAuth是一种授权协议,OAuth协议区分以下四种角色:

    1. 资源拥有者:即用户
    2. 第三方应用:即客户端
    3. 认证服务器:即服务提供商专门用来处理用户统一认证的服务器
    4. 资源服务器:即服务提供商专门用来存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。

    OAuth 2.0支持四种授权模式:

    1. 授权码授权模式(Authorization Code Grant)
    2. 简化授权模式(Implicit Grant)
    3. 密码授权模式(Resource Owner Password Credentials Grant)
    4. 客户端凭证授权模式(Client Credentials Grant)

    4 OAuth 2.0的四种授权模式

    4.1 授权码授权模式流程(重点)

    授权码模式是最严格也是最重要的一种授权模式,其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 请求授权:客户端请求用户授权,允许自己获取和使用用户的特定信息数据
    3. 同意授权:用户同意授权给客户端
    4. 申请授权码:客户端使用用户的授权到服务提供商的认证服务器申请授权码
    5. 发放授权码:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放授权码
    6. 申请令牌:客户端使用用户的授权到服务提供商的认证服务器申请令牌
    7. 发放令牌:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放令牌
    8. 申请资源:客户端使用令牌到服务提供商的资源服务器申请用户的特定信息数据
    9. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将用户指定的用户信息数据发送给客户端

    注意: 授权码授权模式既适用于同一企业的多个系统之间的授权,也适用于不同企业的多个系统之间的授权

    4.2 授权码授权模式详细示例

    这里以知乎客户端、微信认证服务器、微信资源服务器为例 ,这三个相互独立,其中认证服务器使用授权码模式对所有的微信用户进行认证,所有微信用户的数据全部保存在微信资源服务器中,而知乎客户端需要用户登录之后才能进行操作,那么用户使用微信授权知乎客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录知乎客户端的情况下,点击知乎客户端中的链接发送请求
    2. 请求授权:知乎客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    3. 同意授权:用户在微信认证服务器中输入微信账号信息进行认证,并进行授权
    4. 发放授权码:微信认证服务器验证用户微信账号的合法性和是否授权,如果用户账号合法且确定授权,则将授权码发送给知乎客户端
    5. 申请令牌:知乎客户端收到授权码后,使用收到的授权码到微信认证服务器换取令牌
    6. 发放令牌:微信认证服务器验证知乎客户端发送过来的授权码的正确性,如果通过,则将令牌发送给知乎客户端
    7. 申请资源:知乎客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    8. 发放资源:微信资源服务器验证知乎客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给知乎客户端
    9. 解析登录:知乎客户端收到用户微信账号的指定信息后解析并登录知乎客户端
    10. 展示数据:知乎客户端从知乎后台获取数据并展示给用户(这里涉及多步操作,省略)

    4.3 简化授权模式流程

    简化授权模式流程较授权码授权模式少了授权码这一环节,因此叫简化授权模式,其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 请求授权:客户端请求用户授权,允许自己获取和使用用户的特定信息数据
    3. 同意授权:用户同意授权给客户端
    4. 申请令牌:客户端使用用户的授权到服务提供商的认证服务器申请令牌
    5. 发放令牌:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放令牌
    6. 申请资源:客户端使用令牌到服务提供商的资源服务器申请用户的特定信息数据
    7. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将用户指定的用户信息数据发送给客户端

    注意: 简化授权模式既适用于同一企业的多个系统之间的授权,也适用于不同企业的多个系统之间的授权

    4.4 简化授权模式详细示例

    这里以知乎客户端、微信认证服务器、微信资源服务器为例 ,这三个相互独立,其中认证服务器使用简化模式对所有的微信用户进行认证,所有微信用户的数据全部保存在微信资源服务器中,而知乎客户端需要用户登录之后才能进行操作,那么用户使用微信授权知乎客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录知乎客户端的情况下,点击知乎客户端中的链接发送请求
    2. 请求授权:知乎客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    3. 同意授权:用户在微信认证服务器中输入微信账号信息进行认证,并进行授权
    4. 发放令牌:微信认证服务器验证用户微信账号的合法性和是否授权,如果用户账号合法且确定授权,则将令牌发送给知乎客户端
    5. 申请资源:知乎客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    6. 发放资源:微信资源服务器验证知乎客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给知乎客户端
    7. 解析登录:知乎客户端收到用户微信账号的指定信息后解析并登录知乎客户端
    8. 展示数据:知乎客户端从知乎后台获取数据并展示给用户(这里涉及多步操作,省略)

    4.5 密码授权模式流程

    密码授权模式要慎重使用,因为用户需要直接将账号和密码等敏感信息提供给客户端,除非客户端是整个系统的一部分,或者是值得信赖的第三方系统,才可以考虑这种授权方式。其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 要求登录:客户端要求用户登录
    3. 提供账户:用户向客户端提供账号和密码进行登录
    4. 申请令牌:客户端使用用户的账号和密码到服务提供商的认证服务器申请令牌
    5. 发放令牌:认证服务器校验客户端使用的用户授权,校验通过则向客户端发放令牌
    6. 申请资源:客户端使用令牌到服务提供商的资源服务器申请用户的特定信息数据
    7. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将用户指定的用户信息数据发送给客户端

    注意: 密码授权模式主要适用于客户端属于系统的一部分的情况

    4.6 密码授权模式详细示例

    这里以新浪微博客户端、新浪微博认证服务器、新浪微博资源服务器为例 ,这三个共同组成新浪微博系统,其中认证服务器使用密码模式对所有的新浪微博用户进行认证,所有新浪微博用户的数据全部保存在新浪微博资源服务器中,而新浪微博客户端需要用户登录之后才能进行操作,那么用户使用新浪微博客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录新浪微博客户端的情况下,点击新浪微博客户端中的链接发送请求
    2. 请求登录:新浪微博客户端发现用户点击的是需要登录才能访问的链接,于是将用户导新浪微博客户端的登录页面进行登录
    3. 用户登录:用户在新浪微博客户端的登录页面输入新浪微博账号信息进行登录(登录成功即授权成功)
    4. 申请令牌:新浪微博客户端将用户输入的新浪微博账号信息发送到新浪微博认证服务器进行用户认证
    5. 发送令牌:新浪微博认证服务器验证新浪微博客户端发送过来的用户新浪微博账号的合法性,如果用户账号合法,则将令牌发送给新浪微博客户端
    6. 申请资源:新浪微博客户端收到令牌后,使用收到的令牌到新浪微博资源服务器获取用户新浪微博账号信息
    7. 发送资源:新浪微博资源服务器验证新浪微博客户端发送过来的令牌的正确性,如果通过,则将用户新浪微博账号信息数据发送给新浪微博客户端
    8. 解析登录:新浪微博客户端收到用户新浪微博账号信息后解析并登录新浪微博客户端
    9. 展示数据:新浪微博客户端从新浪微博资源服务器获取用户请求的数据并展示给用户(这里涉及多步操作,省略)

    4.7 客户端授权模式流程

    这种授权模式比较特殊,客户端不是以用户的名义向认证服务器申请令牌,而是以自己的名义向认证服务器申请令牌,因此,这种授权模式其它与用户没有任何关系。其主要流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户访问某个应用系统的客户端
    2. 申请令牌:客户端使用自己的名义到服务提供商的认证服务器申请令牌
    3. 发放令牌:认证服务器校验客户端是否是合法的指定客户端,校验通过则向客户端发放令牌
    4. 申请资源:客户端使用令牌到服务提供商的资源服务器申请数据资源
    5. 发放资源:资源服务器校验客户端使用的令牌,校验通过则将客户端申请的数据资源发送给客户端

    注意: 客户端授权模式主要适用于客户端和系统之间默认存在信任关系的情况

    4.8 客户端授权模式详细示例

    这里以市天气系统客户端、省天气系统认证服务器、省天气系统资源服务器为例 ,其中省天气系统认证服务器使用客户端模式对所有的市天气系统客户端进行认证,该省所有市的的天气数据全部保存在省天气系统资源服务器中,那么用户使用市天气系统客户端查看当市天气的完整流程如下图所示:
    在这里插入图片描述

    1. 用户请求:用户在市天气系统客户端中点击链接,请求查看当市天气
    2. 申请令牌:市天气系统客户端将自己的凭证发送给省天气系统认证服务器进行身份认证
    3. 发放令牌:省天气系统认证服务器验证市天气系统客户端发送过来的凭证的合法性,如果凭证合法,则将令牌发送给市天气系统客户端
    4. 申请资源:市天气系统客户端收到令牌后,使用收到的令牌到省天气系统资源服务器获取当市天气
    5. 发放资源:省天气系统资源服务器验证市天气系统客户端发送过来的令牌的正确性,如果通过,则将该市天气数据发送给市天气系统客户端
    6. 展示数据:市天气系统客户端将收到的数据展示给用户

    5 OAuth 2.0单点登录

    单点登录是指在使用多个系统时,只需一次登录就可以使用所有系统,可见,单点登录是针对多个系统而言的,而这多个系统,可能同属于某一个企业(或机构),也可能分别属于不同的企业(或机构),而从2.2小节可知,单点登录的前提是统一用户认证,因此,单点登录主要是结合授权码授权和简单授权这两模式使用。以下两个示例则以授权码授权模式展示两个系统的单点登录流程,多个系统的单点登录流程依此类推。

    5.1 同一企业内部多系统的单点登录示例

    这里以淘宝客户端、天猫客户端、阿里巴巴认证服务器、阿里巴巴资源服务器为例 ,这四个相互独立但同属于阿里巴巴集团,其中认证服务器使用授权码模式对所有的阿里巴巴用户进行认证,所有阿里巴巴用户的数据全部保存在阿里巴巴资源服务器中,而淘宝客户端和天猫客户端需要用户登录之后才能进行操作,那么阿里巴巴用户基于单点登录使用淘宝客户端和天猫客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录淘宝客户端的情况下,点击淘宝客户端中的链接发送请求
    2. 请求认证:淘宝客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向阿里巴巴认证服务器进行认证
    3. 用户认证:用户在阿里巴巴认证服务器中输入账号信息进行认证(认证通过即授权成功)
    4. 发放授权码:阿里巴巴认证服务器验证用户账号的合法性,如果账号合法,则将授权码发送给淘宝客户端
    5. 申请令牌:淘宝客户端收到授权码后,使用收到的授权码到阿里巴巴认证服务器换取令牌
    6. 发放令牌:阿里巴巴认证服务器验证淘宝客户端发送过来的授权码的正确性,如果通过,则将令牌发送给淘宝客户端
    7. 申请资源:淘宝客户端收到令牌后,使用收到的令牌到阿里巴巴资源服务器获取用户账号信息
    8. 发放资源:阿里巴巴资源服务器验证淘宝客户端发送过来的令牌的正确性,如果通过,则将用户账号信息数据发送给淘宝客户端
    9. 解析登录:淘宝客户端收到用户账号信息后解析并登录淘宝客户端
    10. 展示数据:淘宝客户端从阿里巴巴资源服务器获取用户请求所需要的数据并展示给用户(这里涉及多步操作,省略)
      ——————————————————————————————————————————————
    11. 用户访问:随后用户在未登录天猫客户端的情况下,点击天猫客户端中的链接发送请求
    12. 请求认证:天猫客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向阿里巴巴认证服务器进行认证
    13. 发放授权码:阿里巴巴认证服务器发现用户已经认证,因此直接将授权码发送给天猫客户端
    14. 申请令牌:天猫客户端收到授权码后,使用收到的授权码到阿里巴巴认证服务器换取令牌
    15. 发放令牌:阿里巴巴认证服务器验证天猫客户端发送过来的授权码的正确性,如果通过,则将令牌发送给天猫客户端
    16. 申请资源:天猫客户端收到令牌后,使用收到的令牌到阿时巴巴资源服务器获取用户账号信息
    17. 发放资源:阿里巴巴资源服务器验证天猫客户端发送过来的令牌的正确性,如果通过,则将用户账号信息数据发送给天猫客户端
    18. 解析登录:天猫客户端收到用户账号信息后解析并登录天猫客户端
    19. 展示数据:天猫客户端从阿里巴巴资源服务器获取用户请求所需要的数据并展示给用户

    5.2 不同企业之间多系统的单点登录示例

    这里以知乎客户端、豆瓣客户端、微信认证服务器、微信资源服务器为例 ,这四个相互独立,但分别属于三个企业,其中微信认证服务器使用授权码模式对所有的微信用户进行认证,所有微信用户的数据全部保存在微信资源服务器中,而知乎客户端和豆瓣客户端需要用户登录之后才能进行操作,那么微信用户基于单点登录使用知乎客户端和豆瓣客户端进行操作的完整流程如下图所示:
    在这里插入图片描述

    1. 用户访问:用户在未登录知乎客户端的情况下,点击知乎客户端中的链接发送请求
    2. 请求授权:知乎客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    3. 认证并授权:用户在微信认证服务器中输入微信账号信息进行认证,并进行授权
    4. 发放授权码:微信认证服务器验证用户微信账号的合法性和用户是否授权,如果账号合法且确定授权,则将授权码发送给知乎客户端
    5. 申请令牌:知乎客户端收到授权码后,使用收到的授权码到微信认证服务器换取令牌
    6. 发放令牌:微信认证服务器验证知乎客户端发送过来的授权码的正确性,如果通过,则将令牌发送给知乎客户端
    7. 申请资源:知乎客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    8. 发放资源:微信资源服务器验证知乎客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给知乎客户端
    9. 解析登录:知乎客户端收到用户微信账号的指定信息后解析并登录知乎客户端
    10. 展示数据:知乎客户端从知乎后台获取用户请求所需要的数据并展示给用户(这里涉及多步操作,省略)
      ——————————————————————————————————————————————
    11. 用户访问:随后用户在未登录豆瓣的情况下,点击豆瓣客户端中的链接发送请求
    12. 请求授权:豆瓣客户端发现用户点击的是需要登录才能访问的链接,于是将用户导向微信认证服务器进行认证并授权
    13. 授权:此时用户在微信认证服务器中已经认证,因此,用户只需要进行授权
    14. 发放授权码:微信认证服务器验证用户是否授权,如果确定授权,则将授权码发送给豆瓣客户端
    15. 申请令牌:豆瓣客户端收到授权码后,使用收到的授权码到微信认证服务器换取令牌
    16. 发放令牌:微信认证服务器验证豆瓣客户端发送过来的授权码的正确性,如果通过,则将令牌发送给豆瓣客户端
    17. 申请资源:豆瓣客户端收到令牌后,使用收到的令牌到微信资源服务器获取用户微信账号的指定信息
    18. 发放资源:微信资源服务器验证豆瓣客户端发送过来的令牌的正确性,如果通过,则将用户微信账号的指定信息数据发送给豆瓣客户端
    19. 解析登录:豆瓣客户端收到用户微信账号的指定信息后解析并登录豆瓣客户端
    20. 展示数据:豆瓣客户端从豆瓣后台获取用户请求所需要的数据并展示给用户(这里涉及多步操作,省略)

    5.3 比较

    从上述两个单点登录的示例可以看出,同一企业内部多系统的单点登录与不同企业之间多系统的单点登录的流程基本相同,不同的是:同一企业内部多系统的单点登录流程中,只需要用户在首次使用系统时进行用户认证,且认证成功即默认为确定授权,而随后使用其它系统时都不需要再进行认证和授权;而不同企业内部多系统的单点登录流程中,用户在首次使用系统时不仅需要进行用户认证,还要进行授权,而随后使用其它系统时虽然不需要再进行认证,但仍需要再次授权。

    6 小结

    至此,用户统一认证、单点登录、授权的原理与详细流程就全部介绍完成,欢迎聪明的Java猿们留言补充讨论。

    如果觉得本文对您有帮助,请关注博主的微信公众号,会经常分享一些Java和大数据方面的技术案例!
    在这里插入图片描述

    展开全文
  • 数据库服务器的时区不一致,docker的美国时区传到宿主机数据库Mysql的时区会进行自动转换,比如docker传过来时间是8点的,转换成上海时区就是16点,是导致数据库查询不一致的根本原因。 所以一定到保证docker...
  • 以vscodehbuildX为例,建议统一采用prettier格式化插件。 目的:用于适应一个项目组不同开发人员选择不同开发工具做出格式化统一标准。方便git仓库代码管理。 vscode 1.前提是安装Prettier-Code formatter 2.在...
  • 本地消息表是最终一致性的方法,之前的实物补偿是强一致性方法,其区别可以追溯到CAP理论BASE理论。大白话来说,强一致性保证不存在数据不一致的脏时间,最终一致性可能存在脏时间。 消息队列 消息队列实际上是...
  • 统一身份认证单点登录概念研究

    千次阅读 2018-09-28 08:39:14
    在研究、建设单位信息系统的集成登录时,自然想到了统一身份认证单点登录,首先遇到了这样的问题,统一身份认证单点登录的概念是什么,是不是某一个领域的术语,是不是有相应的标准协议以及相关的解决方案,...
  • 一致性成本vs非一致性成本 质量成本: 质量成本(cost of quality)包括在产品生命周期中为预防不符合要求,为评估产品或服务是否符合要求,以及因未达到要求(返工),而发生的所有...一致性成本一致性成本..
  • 制定和统一规范 神技一:ESLint 神技二:Prettier 神技三:VSCode 附录:命名项目结构规范 认识代码规范 先来思考两个问题: 1.什么是代码规范? 2.为什么需要代码规范? 如果你是一个经验丰富的前端开发,你一定...
  • 总线矩阵:业务过程维度的交点; 一致性维度:同一集市的维度表,内容相同或包含; 一致性事实:不同集市的同一事实,需保证口径一致,单位统一
  • MQ消息最终一致性解决方案

    千次阅读 2020-12-21 17:53:52
    多个服务之间使用自己单独维护的数据库,它们彼此之间不在同一个事务中,假如A执行成功了,B执行却失败了,而A的事务此时已经提交,无法回滚,那么最终就会导致两边数据不一致性的问题;尽管很早之前就有基于两阶段...
  • 1、统一使用utf-8编码格式扩展阅读1
  • 文章目录统一javaweb项目mysql数据库时间UTC时间方法及原理前言UTC时间与 GMT时间时间戳时区mysql时间字段解读4种日期类型比如datetimetimestamp区别查看修改时区java里时间类获得系统时间类获得UTC时间...
  • 微服务系统中的数据一致性,你都会了吗

    万次阅读 多人点赞 2021-09-17 23:11:34
    作为一个系统,我们要保证逻辑的自洽数据的自洽。 数据自洽有两方面要求: 抛开代码,数据能够自己验证自己的准确性,也就是数据彼此之间不矛盾 所有数据准确且符合期望 为了实现这两点,需要实现数据的一致性...
  • RabbitMQ消息最终一致性解决方案

    千次阅读 2019-09-29 10:50:38
    RabbitMQ消息最终一致性解决方案 随着分布式服务架构的流行与普及,原来在单体应用中执行的多个逻辑操作,现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的系统带来了水平伸缩的能力,然而随之而来挑战...
  • 统一用户认证单点登录解决方案

    万次阅读 2018-08-22 09:13:36
    本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。 随着信息技术网络技术的迅猛发展...
  • 统一身份认证】——概念扫盲

    千次阅读 2022-02-10 13:30:12
    文章目录一、为什么要有统一身份认证二、什么是统一身份认证三、统一身份认证的实现方案 一、为什么要有统一身份认证 随着企业业务系统的增多,每个系统都有一个用户名密码,那么员工需要记住所有系统的用户名...
  • 三种方式 共享主机的共享主机的localtime 创建容器的时候指定启动参数,挂载localtime文件到容器内 ,保证两者所采用的时区是一致的。 docker run --name -v /etc/localtime:/etc/localtime:ro .... 复制主机的...
  • 分布式系统的一致性问题(汇总)

    万次阅读 多人点赞 2019-09-02 15:32:19
    保证分布式系统数据一致性的6种方案 问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要...
  • 其他收获: conda install pip install的区别: 众所周知,pip的确是python官方(PyPA)推荐的Python软件包安装管理工具,在安装Python软件包时,第一反应应该是pip。正是由于pip是Python官方推荐的“正统”工具...
  • zookeeper 集群一致性原理

    千次阅读 2022-03-25 09:32:59
    ,分别为恢复模式(选主)广播模式(同步)。 恢复模式:也就是zk 集群的leader 节点宕机之后,会重新在剩余的 follower 节点中选出新的 leader,新的leader 选出之后采用广播模式实现各个节点与新的 l
  • gpu精度不一致问题追查 在做模型转换相关工作,但是最近发现转换后的模型精度评测的时候会出现两次评测精度不一致, 模型转换是从caffe转换成量化后的onnx模型,中间会有几个临时模型,分别为original_onnx, 这个是...
  • 事务一致性一定要你的数据库引擎支持,我用的数据库是mysql,常见两种搜索引擎,MyISAMInnoDb,关于它们的区别,网上很多人罗列了,我这里最重要的就是InnoDb支持事务,MyISAM不支持事务。在mysql里面,可以单独为每...
  • 一致性Hash(基于google Guava实现)

    千次阅读 2020-11-02 19:34:13
    一般我们使用的hash就是md5 sha 之类的工具类,在负载均衡会要求类似同一个ip在增加节点时还是定位到之前的节点,这时就要用到一致性hash。具体实现代码参考(基于google Guava): 使用谷歌 Guava 实现 Java 一致性...
  • 什么是数据一致性?

    千次阅读 2019-10-03 10:40:34
    只有当服务端的ZK存在多台时,才会出现数据一致性的问题, 服务端存在多台服务器,他们被划分成了不同的角色,只有一台Leader,多台Follower多台Observer, 他们中的任意一台都能响应客户端的读请求,任意一台也都能接收...
  • 统一门户建设项目最佳实践

    千次阅读 多人点赞 2019-10-30 10:38:28
    很多门户平台产品中已经预置了单点登录功能,可以实现简单的用户管理及统一身份认证,对所有应用系统提供统一的认证方式认证策略,通过单点登录技术,企业内部用户经过统一身份认证系统认证后,无需再次登录就可以...
  • 分布式一致性协议

    千次阅读 2022-03-22 23:37:11
    分布式一致性协议主要分为单主协议,多主协议。它们的核心区别在于是否允许多个节点发起写操作,单主协议只允许由主节点发起写操作,因此它可以保证操作有序性,一致性更强
  • 对于单机系统集中系统是指...1.单机系统的可用性和一致性(ACID)对于单机系统最主要的指标就是数据的一致可用性。其可以用ACID来度量一个系统的可用性和一致性。 Atomicity原子性:一个事务中所有操作都必须全部

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 218,205
精华内容 87,282
关键字:

一致和统一的区别

友情链接: graph.rar