详解：全球最大正版流媒体音乐服务平台Spotify是如何管理服务器的( 三 ) _机器

上面是某个Neep任务的案例。
的大部分逻辑在管理机器安装与回收的Neep任务中都是可用的。从Neep的角度来看，这些任务同样有效。Neep简单地将机器的状态设置为“安装”或“回收”，并请求执行相应操作，然后重启网络。为了简化交付的复杂度，我们将对的调用换成了的 IPMI。
Sid
最初我们在测试Neep时，通过来触发Neep的任务，等到在新堆栈中解决了一些bug之后，我们将两者结合在一起，从而造就了Sid 。
Sid是现在我们的工程师在用来请求和管理机器的主要工具，它是另一个将从获得机器存储数据、从的内部微服务数据库获得的角色数据、以及在Neep中的机器管理任务三项合一的 REST服务，从而使得具有了服务管理性能。Sid拓展了的部分逻辑，以寻找和分配最合适的机器来满足配置请求。Sid优秀的 UI可以轻而易举地在API之上构建，并作为配置请求接口来取代JIRA 。

文章插图
触发Sid配置请求

文章插图
响应Sid的配置请求

文章插图
在Sid中管理机器

文章插图
影响
在公司，Sid和Neep并非唯二获得改进的堆栈，我们还重建了DNS zone的数据生成过程，并且在安装时定期应用自动生成的OS镜像，而不再是只在运行时执行。
结果：响应配置或回收请求的时间可在数分钟内完成，而不再需要数小时。其他小组也基于Sid的API构建了工具，以实现机器群的自动化管理。在的配置堆栈上，Sid是架构与运营中受到赞誉最多的服务，至今为止它已经完成了3500个配置请求，发出了2.8万个Neep任务，包括安装、回收及重启机器，且成功率高达94% 。考虑到数据中心各个机器固有的不可靠性，这个数据已经很优秀了。
2015年中期——最新水平
在2015年，决定逐渐完成迁移，不再使用自己的物理机器，而改用谷歌云平台（GCP）。这一转变对我们提出了挑战：为多团队的工程师管理大量的云计算服务设想方式，同时还不能互相重复。
Pool管理工具
为了避免“非主观意愿”所产生的陷阱，我们小组评估了GCP所提供的管理性能，希望这个工具能够执行的观点与模式，以便为工程师们提供简单明确的办法来获得计算性能。我们认为开发者控制台（）非常强大，但过于灵活，很难引导工程师选择我们偏好的设置；而部署管理器（）也很强大，而且也能执行我们的想法，但在测试中工程师发现它非常难用。
在向谷歌发送了反馈之后，我们开始构建 Pool管理器（SPM）。SPM是一个相对轻量的层面，是基于GCP的API根据具体情况所搭建而成的框架，其中提供了合理的默认预设值。工程师只需指定需要什么角色的机器、需要多少实例、以及放置在哪里，SPM就会确保能实现相应数量的实例，并通过谷歌的来管理，同时Pool可以根据要求来增大或缩小。
Pool管理器管理下的Pool

文章插图
SPM是无状态的服务，主要通过调用Sid和GCP来完成最繁重的工作。
物理池（ Pools）
不会立即取消物理机器群，因此我们在Sid后端建立了对Pool的支持机制。尽管Sid的配置需求模式对我们来说很有用，但太过于倚重个人机器。如果工程师们有办法让物理机器达到与谷歌实例群组类似的性能，是否能够加入类似自动替换故障机器，以及在过渡到GCP时生成随机域名这样的模式呢？Sid对pool的支持允许SPM管理GCE实例以及物理机器，能在无视后端的情况下提供同等的用户体验。