精华内容
下载资源
问答
  • 版权声明:本公众号发布的所有文章,均属于原创,版权归本公众号所有。允许有条件转载,转载请附带底部二维码。一、写在前面在工作中,或多或少都会有接触到一些技术调研的工作。有些是自己在做的,有...

    版权声明:

    本公众号发布的所有文章,均属于原创,版权归本公众号所有。

    允许有条件转载,转载请附带底部二维码。

    一、写在前面

    在工作中,或多或少都会有接触到一些技术调研的工作。有些是自己在做的,有些是看别的同事在做,其中或多或少会遇见一些问题,解决一些问题。有些能做的非常的完美,得出的结论让人无可挑剔,但是有些就显得不那么好。

    因为公司性质的特殊性,很多时候会有一些技术调研的工作需要安排或者被安排到。这里终结一下,如何做好一份技术调研。

    其实调研工作在生活中非常的常见,例如出去旅游的攻略,买一件产品看的测评,这些都是有借鉴意义的,只是很多时候这些生活中的例子是对自己负责,没有做好只是影响自己出游或者损失一次购买机会。

    但是工作中,技术调研做的好与坏,有时候根本上决定了公司在做这个方向上的产品方案,所以,当领到技术调研的任务的时候,尽力做到最好吧。

    二、什么时候需要技术调研

    既然是技术调研,肯定不会是一些有既定方案,大家都了解的技术实现。

    那么,在什么时候,会需要做技术调研,总结来说,有以下几点:

    1. 新技术。
    2. 有人已经做到了,但是不确定细节实现。
    3. 想做 Xxx 功能,不确定能不能实现。

    新技术没什么好说的,我们这个行业迭代快,就拿 Android 说,每次 Google 发布新系统的时候,都有一波技术调研的文章出来。所以类似这种:新系统发布、新的开源项目等等,都被归类到『新技术』的范畴。

    相信每个公司的产品,都有同类产品或者叫竞品。别人家的产品也是有迭代的,有时候会有一些突发奇想的实现。竞品分析是产品经理的一项任务,这时就会有产品经理跑过来问你,这个 App 的 Xxx 功能,原理是什么?我们能不能做到,能实现到一个什么地步?

    最后一类完全是没有依据的,就是一些「某人」创新的实现,但是提出意见的人并不了解提出的创新功能,是否能被现有的技术所实现,如果能实现的话,会不会有什么限制。

    这些,都是技术调研需要解决的事情。

    三、技术调研的时候在做什么?

    既然已经对技术调研进行分类了,那么再来说说如何做好技术调研。

    1、理解需求

    理解需求说的非常的老套,但是确实如此,它是很重要的。

    在开始实施技术调研工作的时候,一定要理解清楚需求。明确这次技术调研的目的,它会被用在什么地方,为什么会有这一次技术调研。

    有明确的需求,就有目的性,可以带着问题去找解决方案。

    2、合理安排时间

    技术调研的对象,一定是新的东西。而技术调研的过程,其实也是一次对未知学习的过程。

    所以合理的安排自己的时间,是非常有必要的,否者很容易沉迷在未知中,无法自拔。要时刻谨记,这是一项工作,需要有 deadline ,无论成与不成,都需要在这个截止日期中,交出一份调研反馈。

    3、尽可能的搜集文档和资料

    对于一些新技术或者成熟的开源项目来说,如果被发布出来,一般很快就会有配套的说明文档和使用文档出来,这些就需要调研人员尽心阅读。

    对于其他一些黑科技范畴的技术调研,其实也很难找到系统的介绍文档。但是一般也能通过搜索引擎找到一些蛛丝马迹,我们只需要尽可能的搜集文档和资料。

    搜集一遍之后,快速的阅读一遍,找出合适需求的文章精细的再阅读一遍,看看是否是我们需要的。

    4、阅读源码

    如果已经搜集到的文档和资料,已经没有办法满足我们的需要了。这个时候只能选择阅读源码了,当然前提是可以拿到源码的场景,例如分析一些开源项目。

    源码是不会骗人的,文档资料中,描述的不清楚的地方,最终源码都会给你答案。

    当然,阅读源码是必要的,哪怕有完善的文档和资料,依然建议在使用此方案之前,简单阅读一遍源码,这样对所使用的方案,有一个基本的认识。

    5、如有必要,反编译

    有些时候,我们并没有具体实现的源码。但是我们有一个『某人』拿来当例子的App,或者同类实现过此功能的 App。

    在没有别的思路的情况下,可以对其 Apk 进行逆向,通过阅读逆向之后的代码,找到实现的思路。也是一个不错的方法。

    关于逆向反编译,可以说的有很多,就不在这里细说了。

    6、多和他人沟通

    当遇上尝试过无法解决或者不理解的地方的时候,可以多和其他人沟通一下,在沟通的过程中找到思路。

    前面提到,既然是技术调研,肯定是没有现成的成熟方案,或者当前团队中,没有人有这方面完善的一个实现经验,等于没人实际用过。

    但是,这不妨碍你和团队中其他人沟通。每个人有自己处理事情的方式,也有自己的思路。当这个调研工作落到你头上的时候,不代表别人不会也在思考这个问题,如何解决。

    沟通也是有技巧的,上来直接就问,这个东西怎么做?呵呵,这是你的工作,不是我的。而且这种没有具体细节的沟通,是没有意义的。所以,要记住,沟通也是有技巧的。

    一个最带着套路的句式就是:

    我想做Xxx功能,已经尝试了 1 、2 、3… 种方式,但是好像没有符合预期,你有什么好的想法吗?

    这样表达清楚你想做什么?你已经做了什么努力,但是没有成功,那么对方在这个具体的上下文中,有没有什么好的想法或者思路,来解决这个问题。

    别人的思路有时候真的是可以茅塞顿开。

    7、调整心态

    就像前面说的,技术调研都是一些没有完整方案,或者团队中,没有人了解细节的技术,才需要被调研。

    所以有时候,技术调研真的是没有结果的,不要把寻求解决方案当成是目的,有时候证实这个技术调研的方案不行,也是一次成功的技术调研。

    有时候确实是因为当前的技术无法实现,『某人』脑洞大开的想法。但是有时候确是因为调研者自身技术水平的局限,而导致无法调研出真实的实现方式。

    可这并不妨碍出你出一份在你能力范围内,详尽的调研文档出来。

    四、调研之后如何反馈

    技术调研之后,无论对调研的技术有没有解决方案,都一定要有一个反馈出来,让大家知道结论是什么。

    一般来说,反馈的形式有:

    1、分享会

    对于一些比较大型并且完整的技术调研,可以考虑开一个技术分享会。当然,分享会是需要有晚上的PPT和配套的说明文档的,这些是需要提前准备的。这样不仅可以活跃大家分享的技术氛围,同时也可以把你在这件事情上,所了解到的知识与大家同步。

    不要把分享会当成一次调研反馈,而是真的当成一次技术分享来做,这样大家也能在你这次调研上学到东西,而不是跟着你的思路来得到你的结论。

    2、文档+邮件

    有时候调研的技术点,非常的单一,没有一些复杂的技术在里面。那么,就无需开一个分享会来耽误大家的时间,毕竟码农们的时间还是很宝贵的。

    哪怕没有分享会,也需要以一份邮件或者文档的形式,将这次技术调研的结果,反馈出来,让大家知道。

    五、反馈内容有需要有什么

    无论是以何种方式对调研结果的反馈,反馈的文档是必不可少的。那么如何写这个反馈文档呢?

    • 说明下技术调研的详细需求。
    • 此次调研都搜集了哪些有效资料。
    • 此次调研,都做了哪些尝试,如果成功,最终选择的是什么方案,为什么选择这个方案。如果没成功,也要说明做了哪些失败的尝试。
    • 如果是有解决方案的技术调研,需要说明使用此方案的一些前提条件、使用场景、会不会有什么问题等。
    • 在调研过程中,碰到的问题,思路是什么样子的,如何解决的。

    调研结果反馈的目的,一方面是为了让大家知道此次调研的结果。另外一方面也是让大家知道此次调研你的思路是什么?做过什么尝试?别人有没有更好的解决方案。

    所以在做完调研之后,一定要尽可能的了解自己调研的内容,因为当你这份反馈发出来的时候,就需要面对大家的提问和质疑,一定会有人问你,这里失败了,是为什么;这一步的尝试,有使用 Xxx 的方式吗?

    六、写在最后

    当你的 Leader 将这件调研任务交给你的时候,大多数情况下是对这件事情有大概了解的,正常来说是符合你当前的技术水平,或者稍微高一点的,所以遇见问题,不要轻言放弃,尽力的解决吧。

    展开全文
  • 日常工作中,或多或少都会有接触到一些技术调研的工作,有些是亲自参与,有些是分配给其他人来完成。 技术调研的过程中,会碰到一些问题,并且解决一些问题。有些技术调研可以做的非常完美,得出的结论让人无可挑剔...

    一、序

    日常工作中,或多或少都会有接触到一些技术调研的工作,有些是亲自参与,有些是分配给其他人来完成。

    技术调研的过程中,会碰到一些问题,并且解决一些问题。有些技术调研可以做的非常完美,得出的结论让人无可挑剔,但是有些就显得不那么严谨,总能让挑剔的人找出一些问题。

    抛开技术调研,我们只看调研的话,在生活中就比较常见了。例如:计划旅行的攻略、挑选一件商品,这些都是有借鉴意义的。只是这些生活中的例子,是对我们自己负责,没有做好可能会影响出游的心情或者损失购买机会。

    可在工作中,技术调研的好坏,能根本上决定了公司在做这个方向上的产品方案,所以,当被分配到技术调研工作的时候,尽力做到最好。

    二、技术调研发生在什么时候?

    既然是调研工作,那在现有的环境下,肯定不会存在确定的方案。有不确定性存在,才需要专人来做调研。

    那么,什么时候会需要技术调研?

    1. 新技术。

    2. “某人” 已经做到了,但是不确定实现细节。

    3. 想做 Xxx 功能,不确定能不能实现。

    新技术没什么好说的,程序员的行业技术迭代快,今天出个小程序、明天出个快应用,就算只是拿 Android 来说,最近 Google 也要发布新系统 P、适配又多了刘海屏。

    这些你只要耐心等,总有一些愿意分享或者乐意尝鲜的人,写出一片文章来分享出来。但是一般这样的文章,总有一些不足的地方,就是考验作者的水平,并且作者也只会站在自己的视角。而在公司为角度,需要确定的方案,而不是模棱两可的结论。

    那些“某人”已经做到的功能,相信每家公司的产品,在市面上肯定不会是独一无二的,一定是存在竞品的。竞品也是在不停迭代的,有时候会有一些有亮点的实现。这个时候就会有产品经理跑来问你,这个 App 的 Xxx 功能,原理是什么?我们能不能做?我想再改进一下你看能不能做到?

    最后一类,就是完全没有依据的,属于产品经理的创新功能。但是提出创新功能的人,并不了解提出的创新功能,是否能被现有的技术所实现,如果能实现的话,需要做什么?可能会有哪些限制?

    这些,就是技术实现需要解决的问题。

    三、开始技术调研

    3.1 理解需求

    理解需求说的非常的老套,但是它真的很重要。

    在开始做技术调研的时候,一定要理解需求方的深层意义。明确这次技术调研的目的,它是用来实现什么需求?

    你只有理解清楚需求方的真实意图,你才能更好的进行技术调研。

    但是既然技术调研充满了不确定性,所以一个详细的功能需求,可能并太不适合技术调研,你可能更需要的是一个泛需求。

    举个例子:

    “小程序-王者荣耀群排行” 的功能,表现出来就是有人分享小程序到微信群里,你进去就可以看到群成员的排位排行信息,这是产品经理所看到的功能。

    此时,产品经理提过来的调研需求是“分享到群里的小程序,能不能拿到群成员的信息?”。你看看官方文档就可以回答“做不到”。再问“为什么它可以?”,“大概是腾讯内部产品有私有接口?”。

    可这并不是产品经理的核心目的,核心目的是想建立分享人和微信群成员的关系。

    那你接到这样的技术调研,你首先看完文档发现无法“直接做到”。但是你发现可以在小程序中,拿到几个数据:谁分享的、分享到那个群、谁进入过这个小程序分享。也就是说,我们只需要通过服务器将这三份数据,建立一个基本的联系方式,我分享出去的这个群,你曾经进来过,我们之间应该是有某种联系的,这其实是产品经理的真实需求。

    所以,在做技术调研之前,充分的理解需求,想清楚需求方到底是想干什么,更深层次的需求到底是什么。

    3.2 合理安排时间

    技术调研,一定是不确定的技术点,而技术调研的过程,也是一次对未知技术的学习过程。

    合理的安排自己的时间,是非常有必要的,否则很容易的沉迷在未知中,无法自拔。要时刻谨记,这是一项工作,是需要有 Dealline 的,无论成或不成,都需要在最后时刻,交出一份调研的反馈。

    3.3 调整心态

    技术调研的始发正是因为技术实现的不确定性以及当前团队技术储备的短板上,所以才需要一次技术调研。

    有时候,技术调研真的是没有结果的,当你找不到解决方案的时候,不要沮丧,这都是正常的,调整好你的心态,才能应对这些不确定。

    我们并不需要把技术调研当成一次找解决方案的过程,有时候严谨的证明“无法实现”也是一个优秀的技术调研。

    3.4 尽可能搜集资料

    一定要尽可能的搜集资料,通读它们,可能解决方案就在某些细节中。

    当你在公开的现有资料中,找不到答案的时候,你也可以选择阅读源码(如果有的话),一些开源项目,文档并不一定尽善尽美,但是因为已经被开源了,我们可以很方便的阅读它的源码。在源码中找答案,要知道源码是不会骗人的。

    针对一些竞品调研的需求,如果找不到头绪,其实还有一条路可以走,那就是对竞品进行逆向分析。通过阅读逆向后的代码,找到实现的思路,也是一种不错的方法。

    其实这些都是方法,都是术,核心就是在你的能力范围内,找到所有可以找到的方法,来完成这个调研工作。

    3.5 向他人寻求帮助

    当你的调研工作,因为一些技术细节无法推进下去的时候,你也可以考虑寻求其他人的帮助。

    虽然正是因为你所在团队没有此方向的技术积累,才需要进行调研,但是并不代表团队成员无法对你提供帮助。每个人有自己的涉猎面,有自己的思考方式,多和其他人沟通,可能能带来一些灵感让我们将调研的工作推进下去。

    当团队成员无法提供帮助的时候,也可以在网上寻求别人的帮助,加社群、发文章都是一个不错的办法。但是要记住提问和沟通的技巧,大多数时候,别人只能给你提供思路,而不是完整的解决方案。

    一个带着套路的提问方式是:

    我想做 Xxx 功能,xyz 已经实现了,但是我并不知道细节。我已经尝试了 1、2、3… 种方式,但是没有符合我的预期,你有什么更好的想法吗?

    这样的套路提问法,表达清楚你想做什么,你已经做了什么努力,但是没有成功,那么对方在这个具体的上下文语境中,有没有什么好的想法或者思路,来解决这个问题。

    重视别人的思路,有时候可以让你茅塞顿开。

    四、反馈调研结果

    技术调研之后,无论是找到了解决方案,或者被认定此方向行不通,都一定要公开的反馈出来,让大家知道结论。

    一般来说,我比较看好的反馈形式有:

    4.2 分享会

    对于一些大型且完整的技术调研,我倾向于开一个技术分享会。当然,分享会需要有完善的 PPT 和配套的说明文档,这些都是需要提前整理和准备的,有时候在这个整理的过程中,你又会发现新的思路。

    分享会不仅可以增强团队的技术氛围,不仅可以提高了自己的演讲和教与授水平,同时也将新的技术知识,在团队中和大家同步,相信不会有人拒绝一场干货满满的技术分享会。

    有心做好分享会的话,我希望你不要仅仅把它当成一次调研反馈,而是当成一次真正的技术分享来做。这样大家也能从你的这次调研上学到东西,而不是跟着你的思路得到你的结论。

    4.2 文档+邮件

    当调研的题目非常的单一的时候,组织一场分享会,无疑是耽误时间的,这个时候可以选择更轻量级的形式:文档+邮件。

    整理出一份调研文档,并以邮件的形式发送到大家手里,和大家同步此次调研的结果。

    无论使用哪种方式进行反馈,最好都要落到文字上。

    五、反馈的内容

    你最终选择使用分享会,或者是文档邮件的形式,在你反馈内容中,都一定要讲清楚技术调研相关的所有细节,以保证读到此文档的人不会对你想表述的内容有疑惑。

    具体的反馈内容,我觉得一般需要包括:

    1. 技术调研的核心需求。用来干什么。

    2. 你都从什么渠道收集到了那些有效的资料。

    3. 做了那些尝试,如果成功,最终选择的方案是什么,并说明原因。如果失败,也要说明做了那些失败的尝试。

    4. 如果找到解决方案,需要说明使用此方案的前提条件、使用场景、会不会有潜在的问题。

    5. 调研的时候,碰到的问题,思路如何。

    调研反馈之所以要写的这么详细,一方面是为了让大家知道此次调研的结果,你的思路是什么样的,你做过什么尝试。另一方面,也是看看别人在你现有的调研基础之上,有没有更好的解决方案。

    不要在意别人对你调研结果的质疑,觉得他是在质疑你的能力,要有独立完整的自尊体系,不受他人所影响。有人提出问题,这说明有人在认真的思考你的问题,和别人辩解的过程,也是让你和大家更清晰的理解此次调研的过程,道理是越辩越明的,技术也是一样。

    六、写在最后

    当你的 Leader 将这件调研任务分配给你的时候,大多数情况下是对这件事情有大概了解的,正常来说是符合你当前的技术水平,或者稍微垫垫脚能够得着的,所以遇见问题,不要轻言放弃,尽力的解决吧。
    当我们在做技术调研的时候,到底需要做什么?怎么做?

    展开全文
  • DID分布式身份标识技术调研

    千次阅读 2021-01-05 16:10:12
    10.25DID调研 分布式身份标识(Decentralized Identifiers, DID) 1.背景 网络匿名⇒账号ID登录⇒授权一键登录⇒分布式数字身份 实现一个用户能自主创建、完全去中心化的身份管理。而区块链的出现,恰恰解决了 DID 去...

    10.25DID调研

    分布式身份标识(Decentralized Identifiers, DID)

    1.背景

    网络匿名⇒账号ID登录⇒授权一键登录⇒分布式数字身份

    实现一个用户能自主创建、完全去中心化的身份管理。而区块链的出现,恰恰解决了 DID 去中心化的问题。

    中心化身份 => 联盟身份 => 中心化身份(DID)一开始的数字认证始是中心化的,比如ICANN管理的域名与IP地址分配,以及PKI(Public Key Infrastructure)系统中的CA(Certificate Authority)证书机构管理的数字证书.中心化身份系统的本质就是,中央集权化的权威机构掌握着身份数据,因为围绕数据进行的认证、授权等也都由中心化的机构来决定。

    身份不是由用户自己控制的。而且不同的中心化网站(比如淘宝、知乎、豆瓣等等)上有一套自己的身份系统,所以都需要你重新注册一个账户。而不同网站自己用的身份系统(及账户对应的数据)之间是不互通的。为了解决这个问题,不同的网站自己联合起来推出了联盟身份(这个概念是首先由微软在1999年提出的)。

    在联盟身份体系下,用户的在线身份有了一定的可移植性。如今的不少网站注册都可以支持第三方登录,比如微信、QQ、新浪微博等。在联盟身份提出后,身份系统就开始走向去中心化了。期间也有很多去中心化的标准、方案出现,比如OpenID。其实就算是一些网站支持的微信、QQ第三方登录,其用户体验也不是很好,而且往往还是需要你用手机号 + 验证码进行注册的。

    综上所述,中心化身份主要的问题就是两个,一是个人并不是真正意义上拥有自己的身份,二是身份无法互通。

    2.基本概念术语

    分布式数字身份包括:分布式数字身份标识符和数字身份凭证(声明集合)两部分:

    2.1 分布式数字身份标识符

    是一种去中心化的可验证的数字标识符,具有分布式、自主可控、跨链复用等特点

    DID本质上是一个全球唯一的地址标识符URL,指向写有与用户身份关联的属性信息的DID文档

    2.2 声明

    是指与身份关联的属性信息。声明可以由身份所有者自己发出也可以由发行人发出,其中由发行人发出的为可验证声明

    往往是个人或机构对自己身份的声称和主张,例如“我叫麦金塔,1984 年 1 月 24 日出生。”

    2.3 可验证声明

    DID持有者可以通过可验证声明,向其他实体(个人、组织、具体事物等)证明自己的某些属性是可信的

    • 可验证声明(Verifiable Credential)提供了一种规范来描述实体所具有的某些属性,实现基于证据的信任。DID持有者,可以通过可验证声明,向其他实体(个人、组织、具体事物等)证明自己的某些属性是可信的
    • 可验证声明可以表示现实事物所具有的相同信息。数字签名等技术的加入,使得可验证的凭证比其物理对等物更不易被篡改,也更值得信任。
    • 可验证的声明可以快速地传输,这使得它们在尝试建立距离上的信任时比物理对等物更方便。
    • 第三方根据他们的记录来确认声明是真实的。例如,一所大学可以证明某人在那里学习并获得了学位。来自权威的证明,要比能够伪造的证明更有说服力。

    2.4 DID文档(Document)

    与DID标识符形成键值对,描述引导与标识的实体进行密码可验证的交互所必需的公用密钥,身份验证协议和服务端点。

    DID文档描述的是与被识别对象进行密码验证交互所必须的DID主体标识、公钥、验证协议、服务端点等,JSON-LD格式,LD(Linked Data),VC的格式也是JSON-LD,该格式可以将文档转换为结构化的数据

    3.基本实现原理

    W3C的DID标准

    在这里插入图片描述

    3.1DID标识符规范格式

    在这里插入图片描述

    • DID的URL标识符

    • DID方法标识符

    • DID方法中特定的的标识符:在整个DID方法命名空间是唯一的

    DID方法规范作用:如何在特定的区块链或者系统创建、解析、管理DID和DID文档,DID规范要包含:Create,Read,Update,Delete

    3.2DID现有的方法

    以bid方法为例——中国信息通信研究院(中国信通院)

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    经过椭圆曲线加密和SM2,输出公钥,并对公钥进行hash处理

    在这里插入图片描述

    BID身份描述对象

    {
      "@context": " https://www.w3.org/2019/did/v1",//@context是数据链接的词汇,这个特定的实例引用了URL
      "id": "did:bid:3acdafe161ef702033bdf895",//标识一个did主体
      "name":"shiweijun",//名称:设置昵称以提高出价标识符的可用性。
      "publicKey": [{//公钥用于身份认证
        "id": "did:bid:3acdafe161ef702033bdf895#keys-1",
        "type": "RsaVerificationKey2018",
        "controller": "did:bid:3acdafe161ef702033bdf895",
        "authorizations": ["all"]"bid": "did:bid: 3acdafe161ef702033bdf895
      }, {
        "id": "did:bid:3acdafe161ef702033bdf895#keys-3",
        "type": "Ieee2410VerificationKey2018",
        "controller": "did:bid:3acdafe161ef702033bdf895",
        "bid": "did:bid: 3acdafe161ef702033bdf895"
      }],
      "authentication": [{//身份验证:一个列表,其中包含用户的身份验证身份属性信息
        "type": "ED25519SigningAuthentication",
        "publicKey": "did:bid:3acdafe161ef702033bdf895#keys-1",
        "proofId":"c1cb770ac94000d946e583d13ea310"
                }],
      "service": [{//服务:每个服务都用属性ID标识。
    			"id": "did:bid: 3acdafe161ef702033bdf895#home_page ",
    			"type": "DIDResolve",
    			"serviceEndpoint": "http://www.caict.ac.cn"
    		}
    	],
    	"proof": {证明:用于证明DDO文档的内容完整性和源可靠性。
    		"type": "RsaSignature2018", 
    		"created": "2017-10-24T05:33:31Z",
    		"creator": "did:bid: 3acdafe161ef702033bdf895#keys-1",
    		"signatureValue": "eyiOiJJ0eXAK...EjXkgFWFO"
    	},
       "Extra":"abc123",
       "isEnable":true,
       "createTime":1561945638,
       "updateTime":1561945638
    }
    

    Create

    在这里插入图片描述

    管理私钥的两种方式:

    1. 生成助记词
    2. 将私钥或者密钥库反馈给用户

    Update:通过调用API进行

    Read:可以通过查询BID或BID的昵称来获取BID文档以及对所有人公开的详细信息。以JSON格式反馈以响应查询

    Delete:通过调用API完成

    身份验证

    在这里插入图片描述

    3.3证明DID与DID文档之间的绑定关系

    1. 根据DID方法规范对一个DID文档进行解析
    2. 验证DID文档的id属性和DID解析出来的结果是否一致

    3.4证明公钥的控制

    静态和动态两种方法:静态方法时使用私钥对DID文档进行签名,这可以证明在DID文档注册前的私钥控制权;若DID文档未被签名,则可以用文档中关于公钥信息来动态证明

    1. 将包含DID文档中的公钥信息和nonce的质询消息发送到DID文档中描述的适当服务端点。
    2. 根据公钥信息验证响应消息的签名

    4.DID CA即DID验证(或者是VC)

    什么是CA: CA是认证中心的英文Certification Authority的缩写。 CA中心,又称为数字证书认证中心。CA中心作为电子交易中受信任的第三方

    CA是干什么的:负责为电子商务环境中各个实体颁发数字证书,以证明各实体身份的真实性,并负责在交易中检验和管理证书。概括的说,CA的核心功能就是发放和管理数字证书。概括地说,CA认证中心的功能主要有:证书发放、证书更新、证书撤销和证书验证。

    涉及的流程内容:

    • CA向用户颁发数字证书(证书包含证书主体的身份,公钥数据,颁发机构名称等)
    • 发证机构对信息进行数字签名形成证书
    • 拥有证书的用户拥有自己的公钥私钥
    • 用CA的公钥解密用户证书,即可得到用户认证公钥

    VC生命周期

    在这里插入图片描述

    1. 发行者Issuer向持有者holder签发issue可验证声明。
    2. 持有者可以将一个或多个可验证声明传输transfer给另一个持有者。
    3. 持有者向验证者verifiers显示present其一个或多个可验证声明。
    4. 验证者验证verify持有者所呈现的可验证声明的真实性。这包括检查撤销可验证声明的声明状态。
    5. 发行者可以撤销revoke可验证声明
    6. 持有者可以删除delete可验证声明

    验证过程

    1. 用户申请注册DID,由用户自己管理

    2. 验证用户DID(用户与DID是否对应),用户出示VC凭证,

    3. 验证者验证VC是由发行者发行的,通过VC中URL找到用户的DID文档,用过DID文档中的公钥再验证用户DID标识

    可验证声明的信任模型

    • 验证者信任由发行者发行的可验证声明
    • 所有实体都相信可验证数据注册表是防篡改的,并且正确记录是由哪些实体控制哪些数据
    • 持有者和验证者信任发布者发布真实的(即,不是虚假的)关于主体的声明,并在适当的时候迅速撤销。
    • 持有者信任存储库安全地存储声明,不会将其释放给持有者以外的任何人,并且在保管声明不会损坏或丢失声明。

    此信任模型与其他信任模型的区别在于:

    • 发行者和验证者不需要信任存储库
    • 发行者不需要知道或信任验证者。

    零知识证明

    为了使用零知识可验证凭证,发行者必须以一种使持有人 能够以增强隐私的方式将信息提供给验证者的方式来发行可验证凭证。这意味着持有人可以证明发行人签名的有效性, 而无需透露已签名的值,或者仅透露某些选定的值。标准做法是通过证明签名知识而不公开签名本身来做到这一点。

    5.答疑

    DID与区块链的解决方案

    DID作为代表实体身份的全球唯一分布式标识符应该如何存储和提供访问,即人们如何访问它们——区块链

    分布式数字身份体系并不局限于区块链技术,更不绑定到唯一区块链平台上,其系统模块可能基于不同的区块链平台实现,甚至是非区块链的其他分布式账本实现

    解决方案及流程

    1. 在身份证明机构、数据持有机构、数据使用机构间搭建区块链网络,机构作为节点接入并注册DID
    2. 由身份证明机构为用户生成DID
    3. 用户授权数据使用机构使用自己的数据
    4. 数据使用机构生成授权凭证(Credential),标明授权对象、数据属主、有效期、授权内容等属性,并使用机构私钥进行签名;数据使用机构可选择将授权凭证生成摘要并写入区块链,达到增信目的
    5. 数据使用机构出示授权凭证给数据持有机构
    6. 数据持有机构通过凭证验证(Verify)接口,验证授权凭证
    7. 验证通过,数据持有机构将数据发送给数据使用机构
    • “区块+共识算法”解决分布式系统的数据一致性问题,将可验证声明和DID文档存证于区块链中

    优势:

    • 可公开访问
    • 可信验证
    • 操作成本低廉
    • 支持用户控制自己的标识符和凭证托管,转换数据治理模型,减少对受信任中介的依赖性;
    • 用户可以管理自己的身份数据,并在之情和授权的基础上将其公开给依赖方
    • 企业可以依靠可验证的用户信息来简化其运营,而不必自己充当数据托管人并处理相关的成本和风险

    DID分布式如何理解

    去中心化身份(DID)利用区块链技术实现让数字身份真正为用户所拥有并支配,就像我们把身份证、护照、户口本这些纸质文件放在自己家里小心保存,只有在需要的时候再拿出来一样,不再有任何中间人(即使是 DID 技术供应商)接触拥有控制用户的身份和数据。

    去中心化+用户自己管理

    关于保护隐私

    • 用户可以拥有多个DID,且DID之间没有任何关联。
    • 加密的数字凭证(VC)和零知识证明(可以向对方证明一件事情,但透露的信息为0)
    • 将用户标识符和凭证加密后存储在区块链上,不可篡改,人人都可以验证
    • DID文档和区块链上不包含个人数据。所有个人资料应保存在DID当事人控制的服务端点后。(服务端点在DID文档中用于表示与DID主题或关联实体进行通信的方式)

    DID文档中没有任何和个人真实信息相关的内容,比如你的真实姓名、地址、手机号等。因此光靠DID规范是无法验证一个人的身份的,必须要靠DID应用层中的可声明验证(VC)

    可验证声明结合数字签名和零知识证明等密码学技术,可以使得声明更加安全可信,并进一步保障用户隐私不被侵犯

    用户对ID身份的控制权

    在DID系统中,用户对自己的身份拥有绝对的 控 制 权 , 用 户 根 据 实 际 需 要 自 主 选 择 使 用 哪些 个 人 身 份 信 息 来 进 行 身 份 验 证 , 并 将 身 份 信息的哈希值 存 储 在 区 块 链 上 , 供 其 他 人 验 证 。

    在数字领域,我们的身份由拥有我们在线帐户的众多平台管理。每当您注册一项新服务时,该公司实际上就已经拥有了您的数字身份的很大一部分。当您使用Facebook或Gmail访问在线服务时,这种情况会放大。在这些情况下,您无法控制或了解共享了多少数据以及如何处理数据。为了在线参与,您必须放弃对个人数据的控制。

    • 每个人在各个平台上会有数十个数字身份
    • 每当注册一项新服务,企业公司网站已经拥有了用户数字身份的很大一部分,且无法控制或了解共享了多少数据
    • 用户仅仅依靠账号+密码+手机/邮箱验证码进行管理使用,存在安全风险

    总结

    DID 技术实现的去中心化身份的体验和用途与传统的数字身份截然不同:首先,你将不只有一个 DID,而是依据身份场合需要的不同拥有无数不同的 DID,每一个 DID 都给你一个单独的终生加密的私密渠道与其他个人、组织或事物交互沟通,因此更好的选择你的身份来交流,更好的保护你的隐私,传统互联网的“人肉”现象将不会再发生;DID 将不仅用来证明的身份,而且可用来交换可验证的数字证书;最棒的是,每个 DID 直接登记在区块链或分布式网络上,无需向中心化注册机构申请。

    疑问

    • 与区块链的关系是什么
    • 分布式如何理解
    • 如何保护隐私
    • DID系统中角色之间的关系:1.用户+数据持有机构+数据使用机构+身份证明机构;2.身份所有者,声明发行人
    • DID流程
    • DID基本原理
    • DID中CA

    VC运行流程

    用户去标识符注册机构注册DID,用户拿到DID和VC凭证,由用户自己管理

    验证用户DID(用户与DID是否对应),用户出示VC凭证,

    验证者验证VC是由发行者发行的,通过VC中URL找到用户的DID文档,用过DID文档中的公钥再验证用户DID标识

    提问解答

    规模问题

    与UUID的区别,或者说DID的优势

    • DID与URN的格式一致
    • UUID强调的是信息实体的唯一性,DID标识符也是唯一的,但DID更强调的是分布式管理和信息的可验证性

    UUID的作用

    应用:

    它能保证每个节点所生成的标识都不会重复,并且随着WEB服务等整合技术的发展,UUID的优势将更加明显。根据使用的特定机制,UUID不仅需要保证是彼此不相同的,或者最少也是与公元3400年之前其他任何生成的通用唯一标识符有非常大的区别。UUID最少在3000+年内不会重复。

    URI,URL,URN

    • URI包括URL,URN;
    • URI是统一资源标识符
    • URI进一步分为定位符(URL)和名称(URN):类似住址和人名(类比人名和地址是不能重复的)

    在这里插入图片描述

    展开全文
  • 豆瓣技术架构调研

    2014-05-22 21:10:13
    一直以来,豆瓣在技术上都给人很前卫的感觉,看起来好像什么新用什么,其实是不是的,他们一直是"用已掌握的技术解决问题",现有的东西如果够用,那么就没必要一定迁移到新的上面去,而转换往往是为了解决当前问题。...

    关键字包括:nginx,lighttpd,quixote,Memcached,mogile FS,Mako,Gentoo Linux,Xapian,spread
    ps:窃以为第一段关于语言的采访,相当[csdn]化 
    你要是愿意,就买一枝三块钱的玫瑰,送给我吧,这城市也是怪让人伤心的,我想死心塌地的爱上你”
       这是一个叫钟童茜的歌手的歌,我在豆瓣网站发现有人评论,才知道了这首有些凄凉的歌曲。你几乎不可能从百度的最流行的mp3的列表中找到它,因为它不是那么有名,也许是这个原因,引发了我采访豆瓣的愿望。接受我采访的是,豆瓣网站的技术总监洪强宁先生和产品经理张贝宁女士。
    本刊记者:好,现在开始,豆瓣是一个非常著名的Web2.0网站,你们的开发语言选择的是Python,我想问的是,为什么选择Python?
    洪强宁:我们选择Python的理由是它是动态语言,具有动态语言的优点,比如开发特别迅速。我们做的是一个Web2.0的网站,这种网站的特点就是always beta,用户的需求在随时发生变化,我们也不断发现新的价值。所以网站的结构和程序会不断变化,如果用Java做,你的开发量比较大,你就难以做出迅速地改变。Python的特点就是开发迅速,你可以在一两个小时,就做出一个功能。或者说已??上线了,用户反映需要某一功能,也可以比较快地做出来。
    本刊记者:这就是TDD,敏捷开发的思路,和传统的方式有些不同。但是会有另一方面的问题,Python的程序员好找吗?在国内会Python的要比会Java程序员少的多。
    洪强宁:对,确实是。在中国用Python的人确实不多,也给我们寻找开发任何人员带来困难。不过从另一方面说,也有好处,因为没有一个学校去教Python,会Python的人都是自己学的,也就是说他知道自己需要什么技术,而且能够通过自学掌握它,包括Python的资料中文比较少,需要学习者接触第一手资料,这都使得Python程序员的平均水平,要比使用其他热门语言的平均水平要高。另一方面Python也越来越流行,在国外比较流行的动态语言有Perl,和Python,现在Python已经超过了Perl。
    本刊记者:不过,在Web开发这方面有许多选择,比如,Java,.NET,和PHP,在这个格局里Python还是比较弱势。
    洪强宁:对,当然,它是新兴语言。在未来,我相信,至少在在Web2.0网站开发方面,它会有自己的一个位置。
    本刊记者:还有问一个问题,Python与Perl比较怎么样?因为Python的面向对象的特性好一些,代码看起来更容易理解一些吧,我以前是用 Perl写程序的,觉得Perl的程序代码看起来比较乱。
    洪强宁:对,Perl 是write once风格的,一个人写完了,过一段时间,可能自己都不能看懂,它确实很强大,但比较适合当作个人工具使用,不太适合团队的开发。Python的哲学是解决问题的最好方式只有一种,这样同样的功能,每个人写出来的程序样子应该差不太多,比较易于理解,更适合团队开发。
    本刊记者:还有一个问题,,有一种说法,认为Python比较慢,在性能方面会不会有问题?
    洪强宁:这个问题可以分两个方面说,首先,说Python慢,这是和编译语言比,比如与C,C++,Java比,在动态语言中,它并不慢,它比Ruby要快,它和Perl性能相当。如果选择动态语言的话,Python并不是很慢。另一方面,如果做网站开发,语言的不是速度的瓶颈,比如我把我们现在用Python写的程序全部用C写,程序当然会快一点,但是改变不是很大。Web网站一般会有很多对IO的操作,比如对数据库的访问,对硬盘的访问响应用户的请求,80%,90%你的时间都花在IO上,语言的速度,相对而言,不是那么重要。也可以这样说,网站的性能主要取决于架构设计的是否合理。因为网站需要响应大量的并发的请求,如果你的设计的不好,即使你用C写的,也可能无法应付。所以更多的考虑是在架构设计上,要使架构体系不会产生速度瓶颈。
    本刊记者:那您能简要地介绍一下豆瓣的架构吗?
    洪强宁:关于豆瓣的系统架构图,首先我们在Web server上做个划分,把网站内容分为动态内容和静态内容。在豆瓣上所有的html都是动态内容,图片都是静态内容。分成两个Web 服务可以做不同的调优。 对动态内容,我们用的是nginx和lighttpd的混合,nginx做负载的平衡,lighttpd通过 SCGi 与application server相连,application server是基于 quixote这个框架写的。
    application server拿到用户的请求,分析用户的url,并且利用外部的资源,比如数据库,组合成一个html,返回。从数据库存取会比较慢,数据库有大量的IO,我们使用cache,我们使用的是Memcached,这是一个分布式的内存的cache,比如你可以用很多机器,每个机器有两个G的内存,我们自己开发了client端来使用它,另外如果用户有搜索请求,我们会用搜索引擎。Xapian是一个C++写的开源的搜索引擎,我们通过Web service去访问它。其他,我们还提供了另外的Web service接口响应用户的请求,比如要访问某个文件。spread是我们最近加了一部分,用户有的请求可以采用这样的异步服务。
    数据库是这样的,两个MySQL做成一对,一个master ,一个 slave,根据应用划分,使得load不会太高。这个图上??的是两对,实际上有三对。还有一个slave,一方面作为备份,一方面用作数据挖掘,因为不能对线上的数据做直接操作。
    对于静态部分,我们也是用nginx,你注意到豆瓣现在有日记的贴图功能系统,用户可能上传很多图片,我们采用的方案是用了mogile FS ,这是一个分布式的文件系统,同时可以做备份,保持高可用性,可以提高很大的IO。
    关于application server,它都是用Python写的。我们是用的MVC方式,Controller我们用的是quixote ,它接受用户的请求,根据这个URL去找到Model的某个具体的函数来执行,它是一个dispatcher,当中会判断用户的权限等。然后再传给View,View根据模版进行渲染,形成网页。View的模版,我们以前是用的是PTL,PTL很高效,最近引用了mako,这是一个比较现代的开源的模版,用它写出的代码比较好维护,比PTL好维护一些.。同时,在使用mako的同时,我们的工程师做了很多加速的工作,现在mako的代码有很多是豆瓣的人写的。
    你如果注意过Python的Web开发框架的话,你会发现Python的有三个比较著名的框架,Django,Pylons,TurboGears,Pylons默认的模版就是Mako。
    下面的就是Model,业务模块,核心是类是User,因为Web2.0是以人为本,我们肯定会有一个User。只有人也做不了事情,还要有物。豆瓣的物,就是Subject,比如书,比如评论,比如小组等。
    与数据库进行链接,我们一个很轻量级的与数据库进行链接,这也是一个开源项目,SQL Farm Manager。这个Web service,豆瓣中有很多用的都是Web service。
    本刊记者:好,还想问您一个问题,Web2.0会不会也在架构设计中也有所体现呢 ?
    洪强宁: Web2.0用户的反复的操作非常多,你需要一个非常流畅的体现。这需要一些技术来实现,比如Ajax;豆瓣花了很多钱很多精力,来提高性能,比如买好的机器,使用Gentoo Linux,为什么使用Gentoo Linux,因为它方便调优。还有,大量的使用cache。在数据库调优方面,我们也花了很大的精力。
    另一方面,Web 2,0是用户提供数据的,用户有很多写操作。这样很多1.0优化方法在2.0中行不通。豆瓣在数据库上用的是分库的方式。除此之外我们还尝试了一些其他的方法。
    本刊记者:我现在想问张贝宁一个问题,您能否谈一下Web2.0社区网站和传统的社区网站的区别?比如天涯论坛,和豆瓣的区别。
    张贝宁:先说一下Web 2.0 的概念,传统网站,用户到这些网站,只是看信息,这些信息是怎么来的呢,比如像Google,它是抓来的,或者像新浪这样的门户网站,是用户给你编好的。你到这样的网站,只是获取信息,你不能创造信息,也不能决定它放的位置。按照业界的理解,Web 2.0相对于Web 1.0,它是以用户为中心的,或者说是以用户创造内容为主,并且可以决定展现方式。你刚才说的传统的社区,在某种程度上,也可以说是2.0的,因为它也由用户提供内容。不过早期的BBS,网站以内容作分类,比如体育,军事,文学等。用户不能形成自己的分类。在豆瓣,用户可以对任何一个话题进行讨论,这完全是用户自主的。这还只是关系到豆瓣的小组的功能,如果拿天涯论坛和豆瓣做比较的话,豆瓣与天涯这样的BBS不同还在于,它首先有一个物的概念,比如书,音乐,和电影。
    本刊记者:我也发现了这点。这样的组织方式,给人的感觉会非常不同。比如我们要查找对余华的小说《活着》的评论,在豆瓣就比较容易找到认真,有质量的评论。而在传统的BBS上,你只能用查找的方式,搜索“活着”这个词,找出的东西,也可能还不是谈论《活着》这本小说的,而只是其中的文本包含了“活着”这个词,而且有很多无意义的吵架帖。豆瓣的组织方式,让人感觉很严肃,雅气。不过,我也发现了一个或许有些不便的地方,比如,我要在讨论德里达的小组回帖,在一般的BBS可以匿名,或具有一个ID就行了,但在豆瓣,我要首先参加德里达这个小组。
    张贝宁:对,是这样的。豆瓣更关心的是人群,就是对同一话题和事物有兴趣的人群,而不是帖子,这与传统的BBS确实有一些区别。
    本刊记者:好,就到这里。谢谢你们两位能够接受我的采访,分享你们的经验与思想。

    ----------------------------------------------------------------

     

    这次的 QCon 会议,《豆瓣网技术架构的发展历程》这个议题差不多是最受关注的。洪强宁在演讲开始告诫大家期望值不要太高,我还是相信不会有人觉得失望的。

    先说几句题外话,整个演讲听下来,我们会发现豆瓣在发展的过程中也是有点弯路,这些是一个网站发展过程中的宝贵财富,能把自己有周折的地方大大方方的拿出来,是难能可贵的事情。尽管豆瓣批露了很多架构细节出来,也不会(也不可能)有哪个公司一拿到这些东西,就能照猫画虎再做一个豆瓣并且超过豆瓣。从某种程度上来说这体现了豆瓣同学们的气度,这是令国内大多数公司汗颜的。很多公司只愿索取,而不愿奉献哪怕一点点出来,用这样封闭的心态对待技术其实是小家子气,守财奴的思维。技术只有为更多人所用才是大道。

    议论说完,再来叙述。写点对豆瓣架构的体会。戏法人人会变,各有巧妙不同。有些东西大家都在用(Nginx),但是有人的用得好,有人用了比不用还差。所以,需要逐渐总结,改进。学习别人的架构设计,不是要照搬,而是借鉴其思想。

    技术的选择

    一直以来,豆瓣在技术上都给人很前卫的感觉,看起来好像什么新用什么,其实是不是的,他们一直是"用已掌握的技术解决问题",现有的东西如果够用,那么就没必要一定迁移到新的上面去,而转换往往是为了解决当前问题。另外,换用新的东西,要有足够的驾驭能力,从演讲中得知,豆瓣曾有几次在临上线前发现基础库的Bug(比如 Libmemcached 的一致性哈希相关的Bug),技术团队能在第一时间有进行修复并且提交给开源社区。否则的话,就变成了一种错误决策了。

    磁盘转速

    小话题。如果可能,直接买 15000 转的磁盘好了。10000 转的磁盘可能省钱,但这东西部署了之后几乎就不太可能升级。所以,如果是初创公司,我的建议就是买高速磁盘,因为业务如果发展快了的话,先前对机器的定位也可能发生变化。

    杜绝远程 I/O 

    在普通的 TCP/IP 网络的环境下,不要进行远程数据写入操作。跨网络操作的延时看似没什么大不了的,但一旦达到临界点就回天乏术。这个事情基本是不撞南墙不回头,有的技术人员总要亲身体验一把才肯罢休。

    持续保持 URL 友好风格

    演讲中有多次提到一致性 URL ,其实体现了豆瓣对 URL Rewrite 的重视,结构调整,或者应用程序变化的时候,URL 最好做到"用户友好"的。这算是"软技术",但是应该加以最大的重视。

    数据库复制延迟问题

    对于 MySQL 复制的环境,如果Slave 上有读取操作,那么有些情况下可能因为 Master 和 Slave 节点数据不一致对用户造成困惑。如果从一致性的角度上考虑,其实也不复杂:,只需要对"知道数据发生了变化的用户"提供一致性就行了(基本上就是发起变更的用户),不知道数据发生变化的用户对数据的不一致有一定的"容忍程度",当然说着简单,实现起来还是需要技巧和精巧的。

    大量小文件同步问题:Merkle tree

    关于大量小文件的同步问题,很多上了规模的网站都会遇到,如果设计得不好或者是比较偷懒,用传统的办法(比如 rsync 之类的老模式)很容易触发问题,也浪费资源。DoubanFS 是用Merkle tree(Hash Tree)的方式进行数据同步的。对这个问题的具体描述可以参见《大量小文件的实时同步方案》。Merkle Tree 是个很精巧的思路,ZFS 在用(refer),Amazon Dynamo 系统也在用。

    不会一会儿又有人留言说:我们早就采用这个思路了...... 我这里预先来句回答:拜托,你早点共享啊?

     

     

    豆瓣网架构-国内python语言网站的王者之路

    豆瓣网对互联网用户来说是知名的Web 2.0社区,但对开发者而言,更重要的是一个应用Python打造的非常成功的Web 2.0站点。豆瓣网已经达到了300万注册用户,另外还有千万级的非注册用户。访问量每天则超过两千万。

    豆瓣Python应用开发经验谈

    豆瓣是一个Web 2.0网站,这类网站的特点就是“Always Beta”,不断有新的产品和功能升级来为用户提供更好的服务。作为使用Python进行开发的网站,豆瓣有效的程序开发配置和版本控制值得我们学习。

    豆瓣的主要开发环境配置就是SVN+Trac+Bitten。豆瓣的版本管理系统使用的是Subversion(SVN),使用Trac来管理协同开发,同时使用Trac的Bitten插件进行持续集成。

    在开发模式方面,由于是Always Beta,豆瓣采用的方式是:站点运行在主分支上,开发者在开发新功能时会建立一个子分支,新功能开发并测试完成后,会更新服务器的主分支版本,之后上线。

    在开发框架方面,豆瓣主要使用Quixote(被称之为“堂吉诃德”,一个轻量级的Python Web框架,简单、高效,代码简洁);后台运行的Web服务主要使用Web.py(web.py也是一个Python的Web框架,简单且功能强大)。

     

    豆瓣网可分割成两大块:一块是前端的Web,也就是用户在浏览器访问的时候会触发一系列的操作,从数据库拿出数据,渲染成HTML页面反馈给用户,这是前端;另外一块是后端,在豆瓣有一个很强的数据挖掘团队,每天把用户产生的数据进行分析,进行组合,然后产生出用户推荐,然后放在数据库里面,前端会实时的抓取这些数据显示给用户。
    豆瓣(架构)设计现在在WEB这一端主要是用这么几种技术:前端是nginx和lighttpd,中间是Quixote的Web框架,后面是MySQL以及我们自己开发的DoubanDB。这些除了Quixote都是一些比较流行的、尖端的技术。Quixote稍微老一点,如果要重新设计的话,可能会在这方面做一些考虑。比如Python社区中的Django、Pylons等等都是可以考虑的,那么在豆瓣的内部的话,我们一般是用web.py,很轻量的一个Web框架来做,也是非常不错的选择,它可能需要自己做的事情多一点。但是,也不太可能完全重新设计了。

    豆瓣网可分割成两大块:一块是前端的Web,也就是用户在浏览器访问的时候会触发一系列的操作,从数据库拿出数据,渲染成HTML页面反馈给用户,这是前端;另外一块是后端,在豆瓣有一个很强的数据挖掘团队,每天把用户产生的数据进行分析,进行组合,然后产生出用户推荐,然后放在数据库里面,前端会实时的抓取这些数据显示给用户。

    豆瓣(架构)设计现在在WEB这一端主要是用这么几种技术:前端是nginx和lighttpd,中间是Quixote的Web框架,后面是MySQL以及我们自己开发的DoubanDB。这些除了Quixote都是一些比较流行的、尖端的技术。Quixote稍微老一点,如果要重新设计的话,可能会在这方面做一些考虑。比如Python社区中的Django、Pylons等等都是可以考虑的,那么在豆瓣的内部的话,我们一般是用web.py,很轻量的一个Web框架来做,也是非常不错的选择,它可能需要自己做的事情多一点。

    豆瓣现在还没有达到数据库分片的程度。最常见的手段是,按照功能分区。我们会把数据表分成几个独立的库,现在是一共有4个库。每个表都是库的一个部分,每个库会有主副两个。通过这种方式来减轻数据库的压力,当然这个是现在的方案,再往后的话,表的行数会增长,到达一定的程度后,还要进行水平分割,这是肯定的。然后我们现在的技术方面,在操作数据库之前,首先获取数据库的游标,有一个方法,这个方法会干所有的事情,我们以后做的时候会从这个方法中进行判断该从哪取东西。这个架构已经在了,只是现在还没有做这一步而已。

    数据库这边主要采用什么解决方案呢?

    在数据库这边,我们主要用的是MySQL。MySQL有一个问题,大文本字段会影响它的性能。如果数据量过大的话,它会挤占索引的内存。那么现在一个行之有效的方法是,我们另外建立一套可伸缩的Key-Value数据库,叫做DoubanDB。我们把不需要索引的大文本字段,放到DoubanDB里面去。MySQL只保存需要索引的Relationship这方面的信息。这样给MySQL数据库降低了压力,也就可以保证它的性能。

    比如说像保证数据的安全性,以及数据库的吞吐量,豆瓣是怎样的策略呢?

    首先DoubanDB会把每个数据在三个节点进行备份,任何一个出现故障都不会影响索取数据。MySQL是通过双Master方案,同时还会带1到2个slave,所以说在MySQL中我们会有三到四个的备份。这点是可以放心的。

    你刚才说到MySQL的双Master方案,这方面会不会存在什么问题?比如说同步的问题,等等?

    在MySQL里面,双Master方案是一个比较经典的方案,我们现在用它很大一部分是为了解决我们同步延迟的问题。在做切换的时候,会出现同步延迟的问题,但其实MySQL的同步速度还是可以的,在切换的时候,我们会忍受几秒钟等待同步的时间。在做脚本的切换的时候,我们会稍微等一下。

    豆瓣的数据表一般是怎么样的规模?

    数据表,这个不好说了,因为不同的表都是不一样的。我们最大的表是“九点”的Entry表,“九点”的爬虫爬过来的所有的文章,现在应该有四千万左右的行数。然后其他的上百万的表也有很多。还有包括收藏表也有千万级的行数。

    在这种海量数据的情况下,对数据表的就结构变更,一定是一个比较麻烦的问题。常见的情况,比如增加一个新的索引,会导致索引好几个小时。像豆瓣之前会存在这样的问题,是怎么解决的呢?

    这个问题曾经让我们吃过苦头,在忽视它的状况下就去改表,然后就锁了很长时间。后来我们意识到这个问题,如果有表的改动的话,我们会先在一个测试的库上试验一下它的时间长短,是不是在可接受的范围,如果是可接受的范围,比如说几分钟,就做一个定时任务,在深夜里面去执行。如果耗时是不可忍受的,就必须通过其他技术手段,我们现在的手段一般是建一个新表,这个新表从旧表同步数据,然后再写数据的时候,也会同步,往两边写,一直到两边完全一样了,再把旧表删掉,大概是这样一个方式。

    刚才您好像提过你们设计了自己的DoubanDB,还有一个是DoubanFS,这两者关系是怎么样的?

    首先是先出来的DoubanFS,我们刚开始的时候用MogileFS来解决我们可扩展图片存储的问题,由于MogileFS有一个重型数据库,这成为了它的性能瓶颈。我们为了解决这个问题,开发了DoubanFS,基于哈希来寻找节点。之后,我们又发现了新的问题,数据库中的大文本字段也会影响性能。所以,我们在DoubanFS的基础上,换了一个底层,做了一些调整,参照Amazon的dynamo思想,搭建了DoubanDB,把文本字段放在DoubanDB里面。做完之后,又反过来用DoubanDB来实现FS,大致是这么一个过程。

    DoubanFS跟DoubanDB的实现,他们在对于内容的安全性,或者内容的冗余性…

    都是(备份)三份。这都是可以配置的,现在的配置是3份。

    DoubanDB就是用什么机制实现的?

    DoubanDB简单来说是这样子:你来一个Key,它是Key-Value数据库,你要写或读的时候,通过这个Key来寻找这个值。拿一个Key对它做哈希,通过Consistent哈希方法去查找它在哪个节点上,然后往这个节点上去写或读。在这个节点上,顺着哈希的wheel顺次的找到第二、三个节点,写的时候会保证这三个节点都写,读的时候是任意一个,如果其中一个读失败了,会自动切换到下一个。

    您刚才提DoubanDB的话,是采用的技术是?

    DoubanDB的底层存储用的是TokyoCabinet,是一个很轻量级、高效的Key-Value数据库。我们在它的基础之上,做了分布式,用这种方式来实现的。

    实际上有一些其他的方案可以解决,比如说像Berkeley DB(简称BDB)、CouchDB等等,你们为什么要选择TokyoCabinet?

    最简单的原因是由于它足够快,实际上BDB跟它比较类似,BDB更加强大一些。对我们而言,我们在这边就是需要一个可靠、高效的Key-Value存储,这两个其实是我们都可以替换的,只要统一下接口就可以。CouchDB的话就是另外一个东西了,它是一个文档型数据库,它不仅仅做了一个Key-Value的工作,它还在这上面做了很多其他的事情,比如它有View的概念,可以进行query。这些TokyoCabinet是没有的,而我们暂时也不需要这些功能。CouchDB是一个很有意思的数据库,我们可能会在其他方面(应用),我们也在研究它。

    在豆瓣专门有一个算法团队,他们的主要工作就是数据挖掘。这边讲技术实现的话,可能就讲不完了。只能讲一些大概,数据挖掘是怎么和前端结合起来的,让用户看见的。每天用户在豆瓣上的操作都会产生很多数据,在豆瓣上面看到的东西,收藏的东西,都会存在数据库或是访问日志。每天这些信息都会传到算法团队的机器上,然后会从这个数据中建立一个稀疏矩阵,你看过什么,干过什么。他们维护了一个很高效的稀疏矩阵运算库,然后用它来做各种各样的尝试,去看是否能得到好的结果,一旦发现这个结果很好,就会把它写到数据库里面。然后用户在访问的时候,前端从数据库中取出推荐给你的数据,然后把这些数据做一些过滤(比如你读过的东西就不再给你展现了)、调整,最后展现给用户。基本上是这么一个逻辑。

    关于Python

    Python语言的历史可以参考《Guido Rossum:打造Google第三大开发语言

    关于Subversion

    Subversion(简称SVN)是一款开源的版本控制管理系统,被认为是CVS的替代者。Subversion的版本库可以通过网络访问,从而使用户可以在不同的电脑上进行操作。从某种程度上来说,允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。

    关于Trac

    Trac是一个开源软件平台,集成了Wiki和问题跟踪管理系统。Trac以简单的方式建立了一个软件项目管理的Web应用,以帮助开发人员更好地写出高质量的软件。Trac采用Python语言开发的,因此Trac的在运行的时候,需要有Python环境的支持。

    关于Quixote

    Quixote是一个Python的Web框架,它基于简单灵活的方案设计,可以进行快速地开发项目,而且使用很多Python第三方模块。通过恰当地配置,可以让Quixote发挥巨大能量,这使得它可以被用于大规模系统当中。

    展开全文
  • “ GPU视频处理技术调研报告 ”

    千次阅读 2018-11-14 07:34:30
    接下来为大家分享的内容可以说是我站在英伟达技术粉丝的角度撰写的“GPU视频处理技术调研报告”,并不代表英伟达官方的观点。我期待通过分享,为处于技术选型中的用户提供GPU的采纳与部署所需的技术依据与路线,也...
  • 数据发现平台可以解决的问题 为什么需要一个数据发现平台? 在数据治理过程中,经常会遇到这些问题:数据都存在哪?该如何使用这些数据?数据是做什么的?数据是如何创建的?数据是如何更新的? 。。。。。 数据...
  • 前言本文链接:http://blog.csdn.net/dreamsever/article/details/53467708前一段时间看到干货集中营 推荐的一个开源项目验证码CaptchaImageView,可用于动态生成验证码,项目地址:...
  • 网上调研:主流网络技术和设备的性能与市场 一当前主要的网络技术的进展以太网的进展 以太网的历史 以太网的相关标准 以太网现状 二当前主要网络技术的应用大学校园使用的技术和设备状况 西南民族大学校园网 具体...
  • 产品经理究竟是干什么

    千次阅读 2017-08-24 11:17:52
    需求调研 业务建模 产品验收 线上运营 注意:这些工作过程并不是每个产品都必须有的,仅仅是做完一个产品的常规过程,有些过程很多时候是被略过的,仅此而已。 以下我来分条说明一下。 产品定义 ...
  • 阿里云,阿里巴巴集团旗下云计算品牌,全球卓越的云计算技术和服务提供商。创立于2009年,在杭州、北京、硅谷等地设有研发中心和运营机构。阿里云创立于2009年,是全球领先的云计算及人工智能科技公司,致力于以在线...
  • 都还不是很了解,今天由阿里云活动代金券免费领取平台“尊托云数zuntop.cn”来为大家介绍一下阿里云以及阿里云产品都是嘛用的,我们什么时候需要用到阿里云。 阿里云创立于2009年,是阿里巴巴集团旗下的云计算...
  • TDS智能选机采用X射线识别技术进行分选,具有设备体积小、系统简单、不用水和介质的特点。原煤井下开采分级后,块煤直接经TDS智能选机进行分选,分选后的块精煤运输至地面,矸石则运回工作面,通过支护充填机...
  • 系统范围和边界定义了DBAS做什么、不做什么、做到什么程度,是DBAS需求分析和系统设计等后续开发步骤的设计依据。 ④确定用户视图。用户视图表示了不同DBAS用户的数据访问/处理需求。 考点3 可行性分析 (1)目的 ...
  • 女孩子该干什么

    2013-07-12 16:14:11
    女孩子该干什么  我的大学室友里有几个外国留学生。有一次,宿舍忽然跑水,我们几个女孩都叉着腰,小心翼翼地站在角落的砖头上给楼管打电话,只有她一个人挽着裤腿,光脚穿着橡胶拖鞋,泡在满屋子的脏水里……...
  • 背景:最近BAT等各大互联网巨头们的校招陆陆续续都准备开始了,可能对于在校的大多数学生来说,不知道如何正确衡量自己掌握的技术,更不知道BAT这样的公司会要求自己必须具备什么样的技术能力。对于Java研发方向的...
  • 最近从兄弟媒体activeTechPros那里得到一份全球08年IT薪资调查报告.activeTechPros是CNET里面一个专门从事薪资调研的部门,所以这份数据有一定的参考价值.目前这个调研正在欧洲,东南亚,印度,澳大利亚和中国等地...
  • 什么使用缓存的Hermes引擎打开页面速度不理想,可能和Hermes的设计有关,我们还在进一步分析中。 八、总结与展望 从目前情况来看,在解决缓存问题之前,我们无法在线上版本直接引入Hermes。 解决缓存问题之后,...
  • 数仓各个层级都在干什么

    千次阅读 2020-03-04 14:59:10
    数仓分层是为了将复杂问题简单化,和解耦。数仓是数据量和数据复杂度...1、问为什么分三层,或者四层,每一层都做了什么,如果不这么分可不可以? 我觉得首先达成一致的是数仓要分层。然后是分几层,ods层是数据贴...
  • 无人驾驶调研

    千次阅读 2017-01-18 20:13:53
    无人驾驶的技术安全风险可以避免吗
  • Apache Karaf调研

    千次阅读 2018-10-09 23:40:19
    (八)CXF CXF 框架是一种基于 Servlet 技术的 SOA 应用开发框架,要正常运行基于 CXF 应用框架开发的企业应用,除了 CXF 框架本身之外,还需要 JDK 和 Servlet 容器的支持。 CXF 继承了 Celtix 和 XFire 两大开源...
  • 干货 :算法工程师技术路线图

    千次阅读 2020-08-28 08:58:06
    来源:知乎;链接:https://zhuanlan.zhihu.com/p/192633890本文仅作学术交流,如有侵权,请联系后台删除导读这是一份写给公司算法组同事们的技术路线图,其...
  • 调研主要要做好两个方向:1,算法调研,它主要是确定可行的技术路线。更具体的说,需要清楚想做的事情是否已经到达落地的水准,也就是可行性的验证。2,市场调研,它主要确定的是,所选中的方案是...
  • ARM虚拟化调研

    千次阅读 2015-10-17 13:22:56
    ===========ARM虚拟化调研报告=================================================调研报告,总的来说调研结果如下:1) 当前ARM虚拟化背景:a) 商用背景:虚拟化很早就有解决方案了,其中著名的是OKL4 Microvisor by...
  • 本文会详细的讲解什么是混合App开发、混合App开发概念、原理、区别、为什么要学习混合App、混合App开发的几种方式以及具体的环境配置和踩坑指南等干货十足。 1-什么是混合移动App开发 苹果上的软件是如何开发出来...
  • 调研表明,越来越多的中国企业开始“拥抱”云计算服务,但其中也不乏对云计算方案的担忧。中国云计算产业发展现状近年来,在数字化转型的热潮下,我国云计算发展正式迎来需求爆发期。...
  • 互联网流行着一句名言:只要站在风口,猪都能飞起来。这句话不只适用于创业者,也适合于咱们广大的IT技术人。对于IT技术领域,曾经有过哪些风口呢?十几年前,做Web开发是风口...
  • Py4j调研

    千次阅读 2011-11-24 21:56:33
    搞了两三个礼拜Jpype,感觉不是很给力,在Django中一直运行不起来,应该是本人技术水平过于低下吧。 今天又见到了貌似可用的Py4j,貌似也可以用于python调用java函数,姑且先调研一下。 Py4j sourceforge网址:...
  • 软件项目中需求调研浅析

    千次阅读 2014-11-19 09:07:55
    大家好,由于本人前段时间一直在客户那做项目的需求调研,所以未及时更新博客,此次博文就本人在做需求调研的体会与大家分享下需求调研的经验...什么是软件项目需求调研? 由于我也是第一次参加项目的需求调研,所以

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,110
精华内容 6,444
关键字:

技术调研是干什么的