5 月 30 日上午，在 QCon 北京全球软件开发者大会上，Authing 创始人即 CEO 谢扬受邀在「研发平台选型方案专场」分享「 Authing 背后的计算哲学」，现场反响非常热烈，多位技术专家提出问题、参与讨论。

互联网应用越来越多，带来很多便捷性的同时，也带来了很多数据孤岛。这些数据孤岛产生了大量的资源浪费，有无数企业和供应商在解决数据孤岛问题。而现阶段大多数企业解决数据孤岛问题都是采用的数据融合方案，Authing 身份云是从根本上解决计算孤岛问题的解决方案，核心理念之一就是：即使是微小的数据块可以很容易地共享。以下为演讲实录：

背景介绍

Authing 是一款身份云产品，身份云的英文全称是 Identity as a Service （IDaaS），也就是身份即服务，总的来说，我们主要提供两种服务，一种是内部员工身份管理（EIAM），另一种是外部用户身份管理（CIAM）。

内部员工身份管理可以这样理解，一家公司有 1000 个员工，如果这家公司使用了 10 个软件，HR 和运维负责人就需要管理 1 万个身份，而我们可以把管理 1 万个身份的成本降低回管理 1000 个身份的成本。

用户身份服务可以用腾讯这家公司举例，腾讯几乎旗下的所有软件都可以使用 QQ 帐号或微信帐号进行登录，这样就造成账号体系内存在非常大的流量并发。有很多公司也面临和腾讯一样的问题，但却没有技术能力解决此问题，Authing 可以帮助这些企业走出大流量并发的困境。

现在，Authing 在全球拥有 100 多家客户，平台上积累了 1 万多名开发者，这些开发者正在使用 Authing 身份云连接 2 万多个应用。

这将激发起整个软件行业的变革，在没有 AWS 和阿里云之前，人们只能自建服务器，有了它们后，大家选择把服务器托管到云上，从前人们自建身份，现在越来越多的企业选择把身份放在 Authing 上进行托管。

在员工身份方面，以前如 AWS 和 IBM 等都有自己的员工身份系统，这些身份系统往往会受到复杂性的限制，它们处于一种定制化、软件化的形态，被统称为 IAM。身份基础设施 Authing 的出现改变了这个局面，将来 Authing 会变成一种身份标准，连接所有人和应用。

这张图揭示了整个云计算的概览，基础设施层也就是 IaaS 层面是 AWS 和阿里云做的事情，往上一层是应用程序栈堆也就是 PaaS 层，是类似于 MongoDB 上云所做的事，再往上就是应用层和用户层，这就是 Authing 所做的事，我们将用户层和应用层通过云化方式托管，来做整个身份的解耦。

Authing 的优势是非常注重开发者友好，我们提供十几种语言的 SDK 和 700+ API，帮助开发者将 Authing 嵌入到任何应用和设备中，例如我们支持开发者一键打通微信八种登录场景和 QQ 身份等所有身份都可以做统一识别。

计算哲学

什么是计算哲学？讲计算哲学之前，我先谈一下什么是计算，简单来说计算分为三种：

• 第一种是数学计算，如「15 = 12 + 3」和「X + X = 2X」；
• 第二种是思维和认知的计算，如「狗 = Dog」和「我爱你 = I love you」；
• 第三种是视觉计算，如「我 ❤ 你」在中文语境下大脑会自动翻译成我爱你，或者我喜欢你。

观察 Facebook 到谷歌的路线图，我们也能得到很多信息，比如我们可以大致推算出路程所用时间多少、距离的长短，甚至可以推算出需要将车开到什么速度才能准时到达，这就是图形辅助人们进行决策，也就是上文所说的视觉计算。

由于纽威尔、西蒙、福多和明斯基等，一大批学者的努力，物理符号系统假说、心灵的表达计算理论，心脑层次假说等相继提出，让思维就是计算、认识就是计算的结论得到验证。

马尔在视觉计算理论和视觉拓扑计算理论上的研究，与通过规则、程序、逻辑进行加工得出的结果，更加完善了整个计算哲学的全貌。

因为今天是软件开发大会，我们来深入讲解下软件领域的计算哲学，在软件领域我们听到最多的一个词就是 I/O，I/O 简单来说就是输入参数得到结论，比如想要做一个认证请求，得到这个请求是否正确。

宏观来看，整个计算机领域几乎都在围绕着 Input 和 Output 进行编程和数据结构设计。这也是我们 Authing 所秉持的计算领域的世界观、核心价值观和核心目标——Make Data Linked Again。

什么叫 Data Link ？我们可以用「在什么情况下把数据库表的字段参数进行拆分」的问题来解答，正确的答案是信息可以被复用的情况下会进行拆表，比如一个人的身份信息，一个人的 ID 可以关联到所有数据，因为这个人的 ID 要被复用，一个人的文章信息，可能既要用于自己的读者界面，也要用于整个网站页面，所以整个软件领域里面所有关于复用的信息都可以抽出来，作为基础设施进行连接。

现在的普遍做法是通过数据库级别的 ID 字段来进行连接，我们所秉持的连接还不太一样，是更大范围的链接，接下来我通过一个例子，讲下数据互联的好处。

现在 Auhing 在全球有 100 多家付费客户，而且这个数字还在快速增长，结果就是我们遇到很多数据问题，导致我站在公司 CEO 的角度无法做出更高效的决策。

这些影响高效决策的数据包括，招聘人数、营销花费、ROI 、销售转化率、客单价、成单周期和怎么最大化利用渠道。这些数据涉及到各个环节和决策链，它们将最终通过一个关键的决策点在公司层面进行决策，这个决策点就是我们还有多少现金流。

拆分来说现金流包含两部分，第一部分是现金，第二部分是应收账款，现金流计算起来比较容易，要减去一些成本，其中包括人力成本、营销成本，还有公司各方面成本。

应收账款计算非常复杂，它包含的因素更多，比如我们签了多少合同，还有多少合同待签，以及已签合同里面对应的有效线索转化率是多少，计算转化率的原因是转化率影响着预算，预算影响着我们在哪些渠道进行营销、广告投放，以及要投入多少钱，最终能够帮我们进行决策。

在没有完整信息化和工业化系统之前，上图中所有箭头都需要人工录入，而 Authing 成功做到了数据联动，现在 Authing 负责增长的同学只需要输入自己的线索，线索确定有效之后会自动转单给销售，销售填写好更新记录，整体现金流、成本、利润以及我们需要增长多少倍，都会自动出现数据结果，实现了一个非常自动化的流程。

在此之前，我需要找财务同事对齐信息，她再去各个部门之间进行流转，最后用 Excel 来做计算，整个过程繁琐、低效和费时。

现在，整体协作变成了网状结构，每个人只需要各司其职，公司整体层面就可以看到全部数据的流传，并及时给到我们进行决策，这就是 Make Data Linked Again，也是我们秉持的计算哲学。

或许有人会问这跟 Authing 有什么关系？我前面提到 Authing 是解耦了身份应用，我们做业务层面，Authing 就从这个层面做到低耦合高内聚，从身份入口，所有企业都在构建软件或者采购软件，所有软件最离不开的就是身份，Authing 作为最大「轮子」，去嵌入或集成到各种各样的应用中，业务效果从各自为战到高效互联，最后让我可以进行秒级决策。

目标签单额和实际签单额、平均客单价和获取的线索量，每个数据不需要经过财务或者增长运营同学进行繁琐的计算，全部自动化处理，基于所有这些数据，就可以预测未来一年的增长，这就是数据互联带来的好处。

我们所有依靠的数据，通过内容营销渠道，每篇内容访问量都可以实现自动化的监测。包括整个商机增长趋势，我们前期做了非常多工作，保证各渠道线上线下所有数据打通，我们还给每名电话销售人员创建一个专属大屏，以上数据最终会汇总到公司增长中心和财务中心的中台里。

值得一提的是实现上述成果，我们没有动用任何一名研发人员，全部工作都是由我们财务人员和我的 COO 来合作完成的。为什么我们能做到这一点？因为我们用了国外一个非常棒的工具 Coda，这个工具特别符合我们对计算哲学的设想，我的 COO 并不需要使用编程技能，就可以在 Coda 里面通过数学公式实现所有数据的连接，而且里面所有图表和表格都可以自由设计与编写。

Coda 以文档为核心，为什么要以文档为核心，后面会讲一下，这是计算哲学的方法论。Coda 可以嵌入到任何应用当中去，同时编程组件也可以支持编程，这就是我们秉持的计算哲学。

我们的业务人员和开发者，只需要在各个数据块之间做关联，比如我整理出来了公司能够帮助我决策的全部流程，业务人员根据流程在各个数据之间做 Link，我作为一个管理者，可以在所有关联数据里面通过图表或其他方式来做探索和决策。

另外，公司所有人都可以在整个关联关系里面寻找所有相关联的数据，所有数据在公司内部都是关联的，我们想打造的是在全社会层面的数据关联状态，就像是在一个现实世界里面，你可以开车去任何一个城市，但在网络世界里面没有办法开车到另外一个应用里面去。我们就要在应用之间，数据层面、身份层面互联。

另外一个领域是即使再微小的数据块也可以很容易地共享，后面我会讲方法论如何做到这一点。

我们整个计算领域的世界观，就是让数据连接互联，让数据可以被再次编程。

因为我们现在遇到很多数据孤岛问题，其实这些成本在早期的时候可以避免，我们就是要从 Day 1 开始让企业远离这些数据无法互联的困扰。因为企业数据对企业来说是非常重要的，价值非常大，价值挖掘在于数据关联程度不高，降低数据关联成本。

 

计算方法论

计算方法论就是让计算世界观落地的一系列方法。

中国很少有人讲计算哲学，但我觉得计算哲学对中国整个计算机行业和信息行业的重要性不亚于马克思主义对于中国的重要性，计算哲学从思想层面、理论层面重新构建了一套基础架构，让所有计算更加有序，更加普适。

在交互层面，我们认为未来所有计算都应该是文档，甚至可以形容为「万物皆文档，文档生万物」，如 Coda 之类的工具最大的特性是可编辑性，我们用 Coda 做了一个公司完整的数据中台，图片里面有图表、文字和表格，这就是文档能够给予的价值。

在语义网领域有一个词是语义控制面板，所有数据都是可以互联的，你的粉丝数据、通讯录数据和聊天数据，它会在各个层面被剥离出来，再汇集到文档里面，表格和功能去完整的定义符合自己标准的数据中台，这就是我们认为在交互层面应该做到像 Coda 一样自由灵活。

同时，我们要提供给终端用户和客户非常简单的操作界面，Coda 还有一个理念叫文档即应用，我可以在手机上查看公司所有的数据，这也是我们认为的下一代计算基础设施应该有的状态。

语义组件就是让人和机器都可以读懂。我举个例子，我们在前端做应用的时候，组件的所有名称标签都是非常语义化的，我可以输入<LoggedIn> 标签，帮我快速判断这个用户有没有登录，所有这些字段在整个语义组件层面都是通用的，这是我们想打造的下一个计算未来时代。

我们认为在语义组件层面有三个很重要的点：

1、数据同步 Data Sync

2、实时展现 Realtime

3、可嵌入性 Embeddability

这三点可以组成非常语义化的组件，举个例子，我们在给外国客户发邮件时，因为距离导致的沟通不顺畅等问题，会出现一些类似于地址填写错误的问题，结果就是要反复的调整转发邮件。

在实现数据同步之后，我可以直接把要调整的内容复制到邮件里，对方的显示界面也会实时变动，这个时候所做的编程就不再是 Dom 编程，而是语义组件的编程，我们将各个语义组件像乐高一样重复进行拼接。

业内也有一些公司在做相关的场景落地，比如微软的 Fluid Framework，另外如 Coda 这种软件是 Fluid Framework 的展示层，还有像 Authing 与声网这些公司将一些业务组件化，这就是我们做的事情，这也是我们认为的计算方法论。

语义组件即编程语言，现在大家还在用「 if else 」 这些逻辑和循环语句来写编程，在将来所有编程都会变成语义组件级别的编程，我们也非常认可这个理想，Authing 就让想让所有组件变得可编程，可嵌入到任何一个应用当中去。

现在有很多 SaaS 服务把整个身份体系和权限体系切换成 Authing，我们发现这里面有大量重复的研发工作，组织架构可以嵌入到客户的应用当中去，我们用这样一套思想和理论，帮助开发者减少公式开发与一些不必要的劳动。

下面我总结一下我刚才讲的计算哲学，落地方法通过文档和语义控制面板、语义组件，来做可嵌入性的标准，我们让整个生态变得像城市一样。

我们可以回想一下，没有共和国之前的城市是什么样子，那时城市与城市之间有城墙相隔，相互沟通只能通过飞鸽传输或使馆来信方式，工业时代之后出现了高速公路，现在马斯克提出了地下隧道 Hyperloop，实现点对点的传输，Hyperloop 就很符合计算哲学的世界观。

将来所有数据之间也可以点对点的进行互联，就像我们前面展示的这张图片一样，没有数据互联之前会有单点瓶颈，有了数据互联之后，每个数据、模块和组织都可以进行非常便捷的互联与连接，这就是我们计算哲学所存在的价值，这也是我们希望能给到中国软件行业和信息产业的一些启发。

 

总结

Authing 计算哲学旨在人、应用和数据之间建立一个互操作性生态。虽然计算哲学的内容在国内非常少，但我认为计算哲学相对于中国整个软件行业的重要性非常大，所以我非常希望大家能够关注计算哲学。

现在企业用户的所有数据在不同应用中被分裂，最看重这些数据的人与数据断开了链接，Authing 的潜力就在于解耦用户身份、数据与应用，从而开启信任和创新的新时代。

大家可以想像在一个网状的数据结构里，每个人都可以无限制的做各种创新，对于公司治理来说，全部有权限的人都可以看到公司的整体状态，让同学们有更多的价值观，更多的控制权和参与感，我们认为在将来所有计算都是以人为中心，都是面向业务，以身份为中心，谁抓住了身份，谁抓住了身份互联，谁抓住了数据互联，谁抓住了计算哲学，谁就抓住了未来。

我们 Authing 的使命和愿景是连接全球人与应用！

 

Q&A 环节

Q1：我听说 Authing 公司在海外有很多客户，如果从 CIAM 场景来看，Authing 在海外最大的竞争对手是谁？

A1：是 Auth0 和 Okta 这两家公司，但 Okta 是一家美国公司，在中国没有提供本地服务，因此在国内访问 Okta 的速度非常慢且不稳定。国外企业如果想在中国开设分公司，Authing 肯定是更好的选择。

而且把 Authing 与 Okta 从身份中台、工作流、目录、应用集成、用户分析、开发组件六个维度与 Okta 进行对比可以看出，目前 Authing 是唯一能够全面替代 Okta 的身份服务提供商。

 

Q2：很多传统企业在做数字化转型或云转型，他们会把很多应用系统上云，不过虽然云的供应商本身有一些解决方案，但没有像专业的 SaaS 服务这么完善，像我们这种小企业可能会倾向于用轻量级的方式替代专业的方法，Authing 公司最优的发展战略是什么？

A2：我们的发展战略是以开发者为中心，永远做面向开发者友好的东西，通过开发者口碑传播和便捷性传播，来获得公司决策层的认可。包括我们整体产品做得很简洁、轻量，我还非常强调整体平台的可嵌入性、可代码性和可编程性，所以任何组件都可以作为一个单独模块给企业和开发者使用，这就是我们的战略。

 

Q3：我是个程序员，我有些财务数据，怎样去做数据和 ID 的关联，让数据联通起来。

A3：以本体为例，本体是描述数据的数据，本体定义了头像的名称只能叫 Photo 而不能叫 Pricture ，通过这样的语义组件来完成数据连接，需要结合 Fluid Framework 特性，在上层定义很多语义化的标签来做数据互联。

假如说不需要程序员的情况下，上图有我们有整个商机获取的表格，下面有线索阶段，对接人姓名，公司规格。大家可以想想程序员怎么做数据关联，表格与表格之间的数据关联，我们有界面来帮助业务人员做快速的数据管理表格创建和 ID 关联。

 

Q4：身份认证流程是什么？是否是嵌入到各个应用厂商的产品里，我的产品是否也要上云，还是仅作为一个入口。安全性又怎么保证呢？100 多个厂商上云之后，如果有泄露或者被攻击的风险怎么防护。

A4：我先回答第一个问题，首先整个流程是符合国际标准协议的，认证过程中可以是云上应用，也可以是云下应用，只要系统网络可以联网就行。第二个有关安全性的问题，把身份拓展到云上反而是更安全的，因为我们有更专业的安全工程师，另外，我再说一下技术上的解决方案，第一是有 PKCE，包括所有收据将通过 AWS 和阿里云的 KMS 加密，最后数据只有客户自己能访问到，主要是通过这三种方式。

 

Q5：我做的业务是偏金融行业的帐户业务，原来我们有想过做 SaaS 化方面的实践，但我们帐户和交易柜台耦合在一起，如果我们做交易结算的时候去查帐户的权限，希望您能够给我一些建议。还有基于帐户上面会有很多「重」的业务，像一些适当性、合规、留痕、校验和人证比对，其实帐户是很忙的，我们虽然可以通过租户的方式来做 SaaS，但我们考虑上面这一层服务是很「重」的。

A5：我们落地了几家银行，银行卡把帐户分成三种类型，客户帐号、内部员工帐号、用户帐号和企业帐户帐号，这三种在银行体系都是分开的，从而可以做到对每个应用的连接。

我建议需要将身份中台单独抽出来，让所有业务都走中台，一种情况下是他们有云计算基础设施，搭建了一个身份云服务，所有应用都切入那个服务，这个服务一般和行内的 AD 或 CAS 进行连接，这个场景会比较复杂 (我们可以私下聊)。