分享

此连结会以新视窗开启此连结会以新视窗开启此连结会以新视窗开启

介绍

在优步这样庞大复杂的公司，内部沟通量很容易变得不堪重负。我们的员工每天使用多个独立系统发送和接收各种通知。这些包括：

1. Pullo——提出对软件工具和服务的访问请求
2. 优步反馈——提供和接收同事反馈
3. Uber Learning – 进行分配的培训
4. 工作日——请假、签订人力资源合同等。
5. ERD-PRD 工具——寻求并提供工程和产品文档的批准
6. UberHub——提出对 IT 基础设施、硬件和软件等的请求。

因此，员工每天都会收到来自多个应用程序的多个操作项和批准请求。统一行动平台或uAct的构建旨在帮助员工掌握分配给他们的任务和行动项目。uAct 将所有此类请求汇总到一个地方，以便员工轻松查看和处理。

动机

员工每天都要通过多个应用程序来提交、跟踪和批准请求。通知通过电子邮件发送给请求批准者。这些很容易在一连串的电子邮件中丢失，增加了请求的周转时间和大量的后续行动！这会导致延误、违反最后期限或公司出现合规问题。

在优步，我们通常会从至少 20 个系统生成定期通知，因此很难管理大量请求。目前，无法在一个地方查看所有待处理的请求。

客观的

创建 uAct 的目的是：

1. 提供员工在多个应用程序中的待处理请求的聚合视图
2. 跟踪、管理请求并采取行动
3. 通过 Slack 批准/拒绝移动中的请求
4. 在关键或长期悬而未决的行动的情况下推动批准者
5. 对各种参数的请求进行过滤/排序，以快速找到重要的参数
6. 维护从 uAct 发起的操作的审计跟踪

建筑学

图1

请求摄取：

uAct 以两种方式聚合来自多个应用程序的未决操作/批准/请求：

1. 实时摄取：从源应用程序实时获取请求
2. 离线摄取：请求通过 cron 作业从源应用程序中获取，并 使用Apache Camel? 框架存储在 uAct 的数据存储中。Request Crawler以增量方式（获取更新的请求）或完整方式（获取所有请求）获取。这些爬网是按预定的时间间隔设置的，根据所摄取数据的性质，每个应用程序的时间间隔可能不同。Request Ingestor将获取的请求保存到Requests Store中。

在 uAct 中查看请求：

图 2

为了在 UI 中呈现请求，请求提供者从实时源应用程序中提取请求，并将其与来自离线摄取的请求存储的相关请求合并。

uAct 的用户界面中有 2 个主要视图：

1. Received Requests View：这是 uAct 的默认视图，显示分配给用户以采取某些行动的请求，例如批准/拒绝
2. 已发送请求视图：此视图显示用户发起的请求并帮助跟踪它们直至关闭

uAct 的 UI 允许用户保存他们的默认视图首选项。这些用户首选项保存在用户首选项存储中。

基于源应用程序提供的 API，用户可以通过两种方式处理他们看到的请求：

1. 被重定向到源应用程序，登陆深层链接请求。然后用户可以在源应用程序本身中执行所需的操作。
2. 在 uAct 平台内采取行动。Action Dispatcher对请求进行身份验证和授权，然后将操作（例如，批准/拒绝）中继到源应用程序。此外，Audit Trail Provider会在Audit Store中创建一个条目，以实现合规性和可见性目的。

uAct 逐步加入新的源应用程序，每个应用程序都具有多种配置。这些在配置存储中维护（独立部署并动态更改）。它包含配置详细信息，例如是否为该用户启用了应用程序；此应用程序允许执行哪些操作，数据是离线摄取还是需要实时获取，超时值等。

功能的试验或推出通过Flipr控制。Flipr 创建了一个功能标志，有助于向特定用户组推出功能、打开/关闭功能等。

uAct 具有用于调试问题的分析、洞察、警报和监控机制。捕获来自 UI 和后端的错误和见解的多个指标，这些指标通过中央可观察性平台进行管理。已设置故障指标以立即检测问题并发出警报。Grafana ?仪表板也是在这些指标之上创建的，用于分析和洞察。uAct UI 已与 Google Analytics 集成，以跟踪活跃用户的数量、点击事件和来自最终用户的其他行为洞察。

后端底层设计

uAct 的后端使用Onion 架构。它提供松散耦合和高内聚性，从而有助于与新的源应用程序轻松集成。

图 3

其组成部分的简要说明如下：

处理程序

• 接收到平台的请求
• 将requests对象转换为entity对象，传递给下一层（controller）
• 将从下一层（控制器）接收到的结果返回到响应对象中

控制器

• 包含应用程序的业务逻辑
• 从网关和存储库协调器获取数据
• 编译并将结果返回给处理程序

网关协调器

• 使用每个应用程序的映射器将请求路由到网关客户端
• 它聚合从多个网关客户端收到的响应

存储库编排器

• 使用每个数据存储的映射器将请求路由到数据库客户端
• 它聚合从多个数据库客户端收到的响应

网关映射器

• 充当 uAct 边界和源应用程序域之间的桥梁
• 将客户端响应映射到 uAct 实体对象

存储库映射器

• 充当 uAct 边界和 uAct 数据存储之间的桥梁
• 将相关数据存储对象映射到 uAct 实体对象
• 处理与各种 uAct 数据存储的交互，每个都满足不同的需求：MySQL 客户端管理用户请求/批准 CacheFront 客户端管理用户首选项

技术考虑

表现

目前 uAct 集成了 10 多个源应用程序；预计随着时间的推移，这个数字只会增加许多倍。尽管如此，应用程序仍应为最终用户保持高性能、可扩展性和低延迟。uAct 遵循混合架构，因此它可以满足源应用程序提供的不同延迟和接口。

如果源应用程序提供直接接口以在用户级别提取数据，并且 API 延迟在允许的范围内，则 uAct 会在运行时提取请求。为了进一步限制延迟，uAct 在应用程序级别并行化请求并采用分页。这样可以同时获取多页数据。getAction API在多个级别请求扇出并具有严格的超时。这确保任何应用程序的降级都不会影响用户的整体体验。

可扩展性

每个源应用程序使用自己的一组字段向 uAct 发送请求。因此，设计的主要重点是使请求结构一致和统一。为解决此问题，uAct 仅在模式级别存储跨源应用程序通用的字段。其余字段位于称为RequestMetadata 的可变大小 JSON 对象中。RequestMetadata 被转换为字符串，以便高效存储、检索和传输。

请求架构：

图 4

uAct UI 提供了解析 RequestMetaData 的灵活性。它使用自定义解析器来解析公共请求卡组件中的特定于应用程序的信息。如下图所示，在第一张图片中，填充了产品、请求级别和描述，而在第二张图片中，报告 ID、上次修改、上次评论和国家/地区填充在同一请求卡组件中。

图 5

图 6

处理不同的应用程序

每个源应用程序都有自己的体系结构/框架/协议。以下是 uAct 处理的一些不同模式：

1. 数据库与 API 交互
2. 基于队列的事件流消耗与批量报告（查询构建器）消耗
3. Rest Https vs. Thrift vs. gRPC 协议
4. 完整系统转储与基于时间的增量转储
5. 按需拉取与持续轮询

为了处理这个 uAct 使用Apache Camel 框架，它实现了企业集成模式并有助于与各种应用程序轻松集成。它提供了丰富的组件库，可以开箱即用地与其他应用程序进行交互。它允许创建新的自定义组件及其关联的路由。路由可作为 REST 服务通过 HTTP 端点调用。Apache Camel 路由提供 cron 作业计划来处理长时间运行的作业。

每个 uAct 路由执行以下操作：

1. 从源应用程序中获取数据块
2. 验证和摄取数据
3. 将特定于应用程序的数据映射到 uAct 的通用数据模式中
4. 将数据提取到 uAct 数据存储中
5. 重复所有这些步骤，直到摄取完成

用户个性化

uAct 提供个性化，确保其 UI 性能不会降低。将来，uAct 将支持启用/禁用任何源应用程序的可见性作为用户偏好的一部分。getRequest API 调用必须与个性化 API 调用顺序进行，因此它应该是低延迟的。

uAct 使用 CacheFront 来存储用户首选项。CacheFront 是 Uber 内部集成的缓存解决方案。它是Docstore之上的透明缓存层，无需与缓存和存储进行交互。它在抽象缓存复杂性的同时提供低延迟读写。

易于入职

在当今瞬息万变的技术环境中，新的应用程序经常被添加到企业生态系统中。uAct 需要能够无缝地载入这些较新的应用程序，而对其现有架构和后端的更改最少或没有更改。

按照图 3 所示的设计，uAct 依次使用 Handler、Controller、Orchestrator、Mapper 和 Client 层。

uAct 选择了一种新应用程序不在处理程序或控制器层进行交互的设计。根据用于源应用程序的摄取类型，uAct 通过以下方法加入：

• Real-time Ingestion源应用：对于这些应用，uAct只需要添加一个新的Gateway Mapper来与源应用客户端进行交互。Controller层的业务逻辑不需要做任何改动，因此不影响现有的功能。这也意味着开发团队的开发工作量最少。
• 离线摄取源应用程序：对于这些应用程序，请求存储在 MySQL 数据库中。形成普通的MySQL查询来按需获取请求。在这种情况下，不需要对后端进行显式更改。

最小化来自平台的重定向

uAct 的目的是尽量减少点击次数和重定向到不同平台的次数。但是，由于技术和安全限制，很少有应用程序不允许第三方与其应用程序集成以执行操作。对于此类应用程序，uAct 利用iFrame来支持操作。

图 7

iFrame 代表现有窗口上的嵌套窗口，如上图所示。iFrame 无需将用户重定向到新选项卡即可加载应用程序的请求页面。启用 iFrame 并不简单，因为内容安全策略禁止在任何网站上呈现外部网页。此外，uAct 域应该在源应用程序的框架祖先中列入白名单。

丰富用户资料

在大多数应用程序中，电子邮件 ID 用作请求的批准者和/或请求者的唯一标识符。如果用户可以看到有关请求者的更多详细信息，例如姓名、个人资料图片、指向 Whober（Uber 的员工目录）的链接等，则用户可以在 uAct 中对请求做出更明智的决定。此要求的主要挑战是确保用户是't 在配置文件丰富 API 降级或失败的情况下受到影响。

图 8

为了解决这个问题，uAct 将主要用户请求与配置文件丰富流程分离。最初，UI 加载没有用户配置文件信息的请求。收集请求中涉及的所有员工的电子邮件 ID。额外的请求者信息在后台延迟加载，同时针对页面上的所有请求。请参考下面显示的 GIF。

图 9

这样，即使在加载配置文件详细信息时，用户也可以继续平台上的其他活动。如果获取员工信息的调用失败，UI 不会中断，只会显示员工的电子邮件。请参阅下面的 GIF，其中未呈现员工的个人资料图像，并且 UI 以蓝色显示默认缩略图。

图 10

信任平台

授权

uAct 充当来自多个应用程序的操作的集中平台，它包含任何其他用户不应访问的个人数据。因此，拥有处理用户数据的身份验证和授权变得至关重要。

图 11

uAct UI 应用程序通过公司范围内的集中身份验证 (Onelogin Auth) 进行管理，因此只有优步员工才能访问它。uAct 平台还在后端服务上提供了额外的身份验证和授权层。对后端服务的任何调用都通过身份和访问管理 (IAM) 传递，确保用户只能访问授权数据。出于调试目的，已定义开发团队的管理员角色。所有管理活动都在 IAM 中进行跟踪。

审计日志

为用户在 uAct 中采取的所有操作维护审计历史记录至关重要。操作可能与重要的 HR 请求、系统/应用程序访问等有关，出于法律和合规原因需要进行审核记录。用户还可以在 UI 的专用视图中查看所有这些操作。

Web 界面上的附加功能

经理和跳过经理的意见

大多数未决请求是针对直接经理或跳过经理的。uAct 提供了一个现成的过滤器来查看来自直接和向下报告的请求（即，我的报告的团队：跳过经理视图）。uAct 保持与源应用程序相同的隐私和机密性。因此，经理和上级经理只能看到那些在审批链中有他们的请求。

图 12

默认视图

uAct UI 为用户提供了创建他们自己的默认视图过滤源应用程序或他们选择的请求者的灵活性。该平台为每个用户存储和呈现自定义的默认视图。

图 13

隐藏/取消隐藏

用户可以通过在 uAct 中隐藏他们不想看到的请求来清理他们视图中的混乱。这不会从 uAct 或源应用程序中删除请求，而只会将其隐藏在 UI 中。用户可以在单独的视图中轻松查看此类“隐藏”请求，并可以在需要时选择“取消隐藏”这些请求。

图 14

下一步是什么？

既然我们已经在 Uber 中成功实施了 uAct，实现了将我们无数的内部通知系统统一到一个单一、方便的平台中的目标，以下是我们计划进一步升级它的一些举措：

添加新源应用程序

利用现有的编排框架，更新的源应用程序将与 uAct 集成，例如 PagerDuty、Jira、GitHub、Coupa、Concur、DocuSign、Asana、ServiceNow、Charter policy 等等。

松弛通知

uAct 平台将与 Slack 集成以进行通知。每当向用户分配任何新请求时，都会通过 Slack 通知用户。此外，用户将能够更改他们的通知偏好，例如频率、包括/排除某些源应用程序的通知等。

综合报告

uAct 平台将通过电子邮件发送所有传入请求的每日或每周汇总摘要/报告。

升级/轻推

轻推功能将允许用户向批准者发送提醒，以加快对请求的处理。这会将请求推送到批准者列表的顶部，这样他们就不会错过它。如果对未决请求没有任何操作，请求者可以将请求升级到审批者的经理。

可操作的公告

有了这个功能，uAct 将允许主持人创建公司范围内的可操作公告，例如进行年度公司调查、执行强制性安全相关任务等。主持人将能够安排发布这些公告、选择目标受众并查看其分析太（观看次数/点击次数）。

个人和可共享的待办事项

uAct 将能够创建个人和可共享的行动项目。用户可以为队友创建行动项目，并利用 uAct 跟踪和跟进这些项目。

作者:

Chankit Bansal

Chankit Bansal is a Sr. Software Engineer on the Workforce Data Experience (WDE) team within the IT Eng org at Uber. Chankit provides tech leadership on a number of applications aimed at improving employee productivity, including uAct.

Manmeet Kalirawana

Manmeet Kalirawana is a Software Engineer II on the WDE team within the IT Eng org. Manmeet has led the design, architecture, and implementation of the uAct Platform from the ground up.

Aasav Badera

Aasav Badera is a Software Engineer on the WDE team within the IT Eng org. Aasav has been instrumental in building integration with source applications in uAct.

出处:https://www.uber.com/en-US/blog/uact-unified-action-platform/