angular 共享组件_使用共享组件构建大规模云基础架构
angular 共享组件
As Unity Ads engineering team, we got invited to the DEVOPS 2018 conference in Helsinki in December 2018, to present how we have approached the challenge of scaling up our systems to handle a 10x increase in load over a period of four years.
作为Unity Ads工程团队，我们受邀参加了2018年 12月在赫尔辛基举行的DEVOPS 2018大会，以介绍我们如何应对规模扩大的系统的挑战，以在四年内应对10倍的负载增长。
Among other things, we discussed what we learned from our first incomplete migration attempt and how we applied that knowledge when successfully migrating our large-scale infrastructure to the Google Cloud platform. This blog post follows up on our talk with more details on the topic, and some general advice for similar big projects.
除其他外，我们讨论了从第一次不完全迁移尝试中学到的知识，以及在成功将大规模基础架构迁移到Google Cloud平台时如何应用这些知识。 这篇博客文章紧跟我们的演讲，提供了有关该主题的更多详细信息，以及针对类似大型项目的一些一般性建议。
Video from the presentation is available here: DEVOPS 2018 – Unity Technologies Keynote, Day 2
演示视频可在此处获取： DEVOPS 2018 – Unity Technologies主题演讲，第二天
Our mission at Unity is to help you become successful with your games, whether you’re a publisher who’s building a business around games through monetization with ads, or an advertiser aiming to acquire new users. Over the last four years, the number of ads shown per week in mobile games integrating our Unity Ads Monetization SDK has increased from 250 million views per week to 2.5 billion views per week.
我们Unity的使命是帮助您通过自己的游戏取得成功，无论您是通过通过广告获利来围绕游戏开展业务的发行商，还是旨在获取新用户的广告商。 在过去的四年中，集成了Unity Ads Monetization SDK的移动游戏中每周展示的广告数量已从每周2.5亿观看次数增加到每周25亿观看次数。
For an ad platform like Unity Ads, the amount and quality of data we have access to improves our ability to show relevant ads to users. This helps advertisers reach the intended audience and publishers to receive higher ad revenue in their games.
对于Unity Ads之类的广告平台，我们可以访问的数据量和质量提高了向用户展示相关广告的能力。 这可以帮助广告商吸引目标受众，并帮助发行商在其游戏中获得更高的广告收入。
The above slide shows the growth in traffic, and how we from engineering have introduced architectural changes to allow our system to scale accordingly. Like many other successful software products, we started out with a monolith system, all the logic for handling publishers, advertisers, as well as the ads delivery itself was in the same codebase. With the increased load on our services, we had to address different aspects of scaling our services, from splitting the codebase into a microservices based architecture, to migrating and consolidating our legacy cloud infrastructure.
上面的幻灯片显示了流量的增长，以及我们从工程学方面如何引入体系结构更改以允许我们的系统进行相应扩展。 像许多其他成功的软件产品一样，我们从整体系统开始 ，用于处理发布者，广告商的所有逻辑以及广告投放本身都在同一代码库中。 随着服务负载的增加，我们必须解决扩展服务的不同方面，从将代码库拆分为基于微服务的体系结构，再到迁移和整合我们的传统云基础架构。
The primary goal for the engineering teams at Unity Ads is, simply put, to enable fast growth in our monetization business. So when we have experienced a 10x increase in the number of requests to our backends, we obviously had to scale our systems accordingly to continue serving ads, and also improve the tools that allow publishers, advertisers and our account managers to handle the increased amount of games using Unity Ads.
简而言之，Unity Ads工程团队的主要目标是使我们的获利业务快速增长。 因此，当我们收到的后端请求数量增长了10倍时，我们显然必须相应地扩展我们的系统以继续投放广告，并且还改进了工具，使发布者，广告客户和客户经理能够处理数量增加的使用Unity Ads的游戏。
Solving a seemingly steep technical challenge, especially on a larger scale, most often involves addressing the people and organizational aspects of the problem. In our case, the challenge was to regain ownership of an infrastructure which was originally built when our service had a much smaller load than is the case today, as shown in the diagram above.
解决看似陡峭的技术挑战，尤其是大规模解决问题，通常涉及解决问题的人员和组织方面。 在我们的案例中，挑战是要重新获得最初构建的基础架构的所有权，该基础架构是在我们的服务负载比今天小得多的情况下构建的，如上图所示。
我们首次尝试迁移基础架构 (Our first attempt to migrate infrastructure)
To ensure our infrastructure and services would be able to scale in the future and reducing bottlenecks in the organization, we knew we needed to perform a migration of our cloud infrastructure, both technically, but also in a way that would allow development teams to fully own their services, including cloud infrastructure parts, in order to reduce external dependencies for teams.
为了确保我们的基础架构和服务能够在将来扩展并减少组织中的瓶颈，我们知道我们需要在技术上进行云基础架构的迁移，而且还需要使开发团队完全拥有他们的服务，包括云基础架构部分，以减少团队的外部依赖。
Our first attempt to migrate was kicked off mid-2017. However, relatively early after starting the project, we noticed the following problems in our setup of the migration, which eventually lead to the decision of stopping the project, as it was clear it would not result in the outcome we were looking for:
我们的首次迁移尝试于2017年中开始。 但是，在开始项目的早期，我们注意到在迁移设置中存在以下问题，最终导致决定停止该项目，因为很明显，这不会导致我们想要的结果：
- Lack of clear ownership of migration, causing individual projects to stall, as there simply wasn’t a clear process of who would be driving the migration, operation (Ops) or development team. 缺乏对迁移的明确所有权，导致各个项目停滞不前，因为根本没有一个明确的过程来确定谁将推动迁移，运营(Ops)或开发团队。
- The project was primarily Ops based, and development teams involvement was limited, so we didn’t have required knowledge about infrastructure spread to development teams. 该项目主要基于Ops，并且开发团队的参与受到限制，因此我们不需要将基础架构知识传播到开发团队。
- Development teams continued developing features, so migration was a constant moving target. 开发团队继续开发功能，因此迁移是一个持续不断的目标。
- We did get some smaller services (in terms of traffic volume) migrated but failed to move major large traffic components over, as critical issues were identified too late in the migration process, and it was unclear who was responsible for addressing those. 我们确实迁移了一些较小的服务(在流量方面)，但未能移走主要的大型流量组件，因为在迁移过程中发现关键问题为时已晚，目前尚不清楚是谁负责解决这些问题。
- The project wasn’t connected to business goals, which meant migration would often get prioritized lower than the development of new features. 该项目与业务目标无关，这意味着迁移的优先级通常低于开发新功能的优先级。
开发团队推动云基础架构迁移 (Development teams driving the cloud infrastructure migration)
The primary learning from our first attempt above was to address the lack of clear ownership in the migration process, giving the development teams ownership and control of the infrastructure, reducing external dependencies for teams. Based on this we started our current cloud infrastructure migration project in August 2018, and at this time we’re almost done migrating all of our services to the Google Cloud infrastructure. To learn more about our partnership with Google Cloud, see this blog post.
我们上面的第一次尝试的主要学习是解决迁移过程中缺乏明确所有权的问题，使开发团队对基础结构拥有所有权和控制权，从而减少了团队的外部依赖性。 基于此，我们于2018年8月开始了当前的云基础架构迁移项目，此时，我们几乎完成了将所有服务迁移到Google Cloud基础架构的工作。 要了解有关我们与Google Cloud合作的更多信息，请参阅此博客文章 。
We wanted to empower individual development teams so they could control and own as much of their infrastructure as possible. At the same time, we needed to reuse shared modules. So we came up with an “internal open-source model”, meaning that typically one team is the maintainer (in open source terminology) of a module, keeping track of changes, reviewing PRs and basically ensuring that other teams are able to easily contribute to the module.
我们希望授权各个开发团队，以便他们可以控制和拥有尽可能多的基础架构。 同时，我们需要重用共享模块。 因此，我们提出了一个“内部开放源代码模型”，这意味着通常一个团队是模块的维护者(使用开放源代码术语)，跟踪更改，审查PR，并基本上确保其他团队能够轻松地做出贡献到模块。
We do have a small DevOps team, however, the role of this team is to work with the development teams on identifying common infrastructure requirements across teams, and always working closely with the teams to help them without blocking their work.
我们确实有一个很小的DevOps团队，但是，该团队的作用是与开发团队一起确定各个团队之间的通用基础架构需求，并始终与团队紧密合作以帮助他们而不会妨碍他们的工作。
结论 (Conclusion)
Based on our learnings, we have addressed the problems we faced in our first migration project in the following ways:
根据我们的学习，我们通过以下方式解决了我们在第一个迁移项目中遇到的问题：
- “Lack of clear ownership” and “Primarily Ops based approach”: Each service is owned by a single development team, which is driving the migration, reaching out to others when help is needed. Migration projects aren’t handed over to other teams in the middle of the process. “缺乏明确的所有权”和“基于Primally Ops的方法”：每个服务都由一个开发团队拥有，这将推动迁移，并在需要帮助时与其他人联系。 迁移项目不会在流程的中间移交给其他团队。
- “Not connected to business goals” and “Development teams continued developing features”: Migrating to Google Cloud became a business objective, meaning that the majority of development team members would work solely on migrating, avoiding context-switching between migration and feature work. “与业务目标无关”和“开发团队继续开发功能”：迁移到Google Cloud已成为一项业务目标，这意味着大多数开发团队成员将只从事迁移工作，而无需在迁移和功能工作之间进行上下文切换。
With the above model, we have found a healthy balance between having each team own feature delivery and deployment of their services, and at the same time reducing duplicate work across teams by reusing shared components used in multiple services.
通过上述模型，我们在使每个团队拥有各自的功能交付和部署服务之间，以及通过重用多个服务中使用的共享组件，减少了团队之间的重复工作之间找到了一个健康的平衡。
We’re working on a follow-up in-depth blog post describing the tools we’re using, i.e. Kubernetes, Terraform, Jenkins/Gitlab CI and Helm. If you love working on cloud infrastructure just as much as we do, consider joining the team! Check out open positions on https://careers.unity.com.
我们正在编写一个后续的深度博客文章，描述我们正在使用的工具，例如Kubernetes，Terraform，Jenkins / Gitlab CI和Helm。 如果您像我们一样喜欢在云基础架构上工作，请考虑加入该团队！ 在https://careers.unity.com上查看空缺职位。
angular 共享组件