文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

当今在软件行业,所有人都在讨论DevOps(Development和Operation的组合)的实践,我们看到过大量的同时采用DevOps和微服务(Microservice)架构的软件驱动的组织。

Image title

单片软件 -> 多层架构软件 -> 服务导向架构软件 -> 微服务 -> “无服务”

迁移至Microservice架构

“Microservice(微服务)”是一个强大而花俏的词语,对吗?每个人都在讨论微服务,所以为什么你不这么做?

从 这里 可以看到一些迁移到微服务架构的好处。

每个人都仅仅在讨论迁移到微服务架构的正面效果。你是否真的需要微服务架构?为了想清楚这一点,你需要问自己下面的问题:

第 1 段(可获 1.06 积分)
  1. 你希望你的服务达到怎样的独立程度?

  2. 你的代码组织得有多好?存储在单一的代码库还是多个代码库?

  3. 你的团队能处理什么程度的运营复杂度?

  4. 你是否有一个准备就绪的持续交付(Continuous Delivery )的平台?

  5. 你的团队是如何组织的?他们是否了解不同的工具集以及微服务架构?

第三点和第四点非常重要,因为他们讨论的是运营复杂度和持续交付平台。微服务大幅提高了运营复杂度,这是因为你需要从一个非常基本的角度来重新思考你的运营。

第 2 段(可获 1.06 积分)

你需要考虑下述的几个方面。

基础设施

定义微服务对基础设施的需求,然后为每个微服务提供并维护基础设施的工作会增加一个级别的复杂度,这是大多数致力于单片软件的运营工程师所不习惯的情况。此外,随着这些微服务扩容和缩容,基础设施需要自动随之扩展或收缩,因此你需要非常复杂程度的自动化。

负载均衡和扩展

你很可能需要一个比单片软件应用复杂得多的扩展策略。单片软件通常是整体扩展的(X轴方向)。但对于微服务,你需要找出在需求出现峰值时,到底是需要扩展所有服务还是所有服务的一个子集。你的运营团队需要理解Y轴方向的扩展,因为微服务方法是与之一致的,同时为了获得X、Y轴方向扩展带来的好处,运营团队还需要理解Z轴方向的扩展。

第 3 段(可获 1.84 积分)

服务发现

在微服务的世界里,服务实例集会随着扩展和升级而动态变化。同时,服务会动态部署在网络的不同位置,因此你需要一种发现新服务实例的方法。对此,我们推荐类似Consul(一种服务发现和配置共享的服务软件)的服务注册的方式,这种方式在我们这工作良好。

监控

我们需要为每个微服务配置和维护监控,这为运营工程师增加了复杂度。同时,监控解决方案需要应付部分服务扩容或缩容的情况。

在你决定迁移到微服务架构前,运营复杂度本身(的提升)会给你带来些许犹豫。只有你意识到了微服务带来的挑战并且有一个计划来应对他们,迁移的过程才不会那么痛苦。

第 4 段(可获 1.59 积分)

你是否有准备就绪的持续交付平台?

像Netflix、Amazon(亚马逊)等推广微服务的组织,都有足够的资源为他们的微服务自行建立自定义的持续交付流水线。然而,不是所有组织都能负担得起这么做。你有可能要依赖像  ShippableCircle CIXebiaLabs 或 Travis CI 这样的外部平台为你做这些事情。

第 5 段(可获 0.74 积分)

文章评论