写点什么

微服务部署面临的挑战

  • 2016-04-20
  • 本文字数:2005 字

    阅读完需:约 7 分钟

以前,我们邀请几位嘉宾讨论了他们在开发微服务时遇到的挑战,比如 Fred George Dustin Huptas 和 Andreas Schmidt 。近日,Usman Ismail 参加了一场小组会议,讨论了微服务持续交付面临的挑战,并决定随后详述其中的部分重点内容。他首先讨论了微服务其中一个基本原则的缺点,那允许大型团队通过快速原型和迭代以一种更加敏捷的方式推进(软件)开发:

不过,微服务显著增加了开发团队的运维和工具负担。每个服务都需要一个部署管道、一个监控系统、自动报警、轮流电话值班,等等。对于大型团队,所有这些负担都可以视为提升特性开发效率的合理代价,是创建这些系统值得付出的努力。不过,在小型团队中,如果同一批人负责所有的服务,那么无论如何,为多个项目复制管道都是开销上的浪费。

接下来考虑的是运维负担。在 Usman 看来,使用微服务或单体架构,如果推出了一个服务或组件的不良版本,就需要回滚系统,而且如果遇到资源限制,则(常常)可以横向扩展。不过,使用微服务,你需要更多的监控和自动化才能检测出哪些服务需要回滚,并确定回滚一个服务对其他依赖它的服务产生什么影响,等等。

如果你有自动报警系统(你真应该有一个),那么你需要把报警信息发给服务所有者,并为多个服务维护一个电话值班时间表。在小型组织中,负责不同服务的人群之间会有很大的重叠。这就是说,我们必须针对这些服务协调时间表,以确保同一个人不会被许多服务钩住,让人们在轮流电话值班之外得到一些喘息。由于这些以及上一节中提到的原因,最好是开始引入多个微服务的开销之前有一个单体架构,并把所有的运维工作安排妥当。

然后当然是微服务一个基本特点——一个在传统单体应用中可能不会提到或者很少提到的特点:分布式。这引发了一个古老的问题,就是在分布式环境中调试,我们过去已经提到过许多次,在微服务这个术语被创造出来以前。原先,Joyent 首席技术官 Bryan Cantrill 探讨过在生产环境中调试微服务。Usman 认为,没有一个集中式的微服务日志是一种致命的缺陷:

而且,在规模比较大的情况下,有一个单独的监控系统(比如 datadog、grahite)和一个单独的日志聚合系统(比如 ELK、loggly 或 Splunk)是不可行的。在这种规模下,可视化指标和日志数据是一个大数据问题,最好在一个地方解决。

对于小组会议的最后一个重点,Usman 提到了部署协调和版本管理。文章认为,微服务和单体应用的其中一个重大差别是前者是一棵服务依赖树,而后者是一个图:

例如,在单体模型中,一个典型的服务栈可能包含一个“Web 组件组合(web array)”,它调用一个缓存层、数据库层,可能还有一些独立服务,比如身份验证,等等。在微服务模型中,你会有一个连通图或者服务网络,每个服务都依赖于几个其他的服务。有一点很重要,就是要确保这个图是一个有向无环图(DAG),否则你会陷入依赖地狱,可能还会遇到分布式堆栈溢出错误。

有趣的是,Usman 的文章接下来总结了嘉宾们提出的一些指导原则:

参加小组会议的嘉宾,没有哪个人对他们的微服务系统十分满意,也就无法为如何构建这样一个系统提出任何类似指南的东西,不过,我们确实提出了一些经验法则或者一般的指导原则,包括下列这些。

这些原则可以总结为:

  • 微服务需要大量的基础设施用于开发和部署,因此要使用一个平台。“ Kubernetes Swarm Mesos 以及其他类似产品可以提供很大的帮助,但你仍然需要使监控、调试、“连续管道(continuous pipeline)”和服务发现机制一体化。”
  • 为了实现可再现、可靠的自动化,不要通过人工过程定义系统的任何东西。“任何东西都必须通过代码定义,可测试,可再现。例如,服务器 / 虚拟机的配置应该使用 docker-machine、puppet、ansible 等进行编排。
  • 开发或使用集中式监控、日志和报警。“单体服务就像一个深受喜爱的宠物,你知道它所有的怪癖和习惯,而微服务就像牲畜;你要它们全部都差不多一样,并作为一个普通的畜群进行管理,而不是一个个体。”
  • 务必确保向后向前兼容。
  • 将大型微服务部署可视化为一个网络。“监控和管理一个大型微服务部署同管理一个网络系统十分类似。”

所有的建议都是基于来自各类公司的嘉宾们的集体经验。那些建议一直随着时间演变,将来可能会随着经验的日益丰富而继续演变。在某种程度上,Usman 最后的评论附和了 Vijay Alagarasan 去年在演讲“7 种微服务反模式”中所讲的内容:

[微服务] 并不是解决构建和运行大规模分布式软件基本问题的魔弹。微服务架构迫使你更谨慎地遵循最佳实践和自动化工作流。本次讨论的一个重要结论是,除非你愿意将大量的时间和资源从特性开发工作转到构建和维护一个服务框架上,否则最好避免进入微服务的世界。不过,如果你能够投入时间构建一个很棒的服务框架和工作流,那么你将完成重大转变,成为一个更敏捷、更有生产力的组织。

我们总是在寻求更深入的微服务经验,有好的经验,也有不好的经验,因此,或许你想自己对 Usman 的工作或讨论作出评判。

查看英文原文: Challenges of Microservices Deployments

2016-04-20 19:003430
用户头像

发布了 1008 篇内容, 共 387.9 次阅读, 收获喜欢 344 次。

关注

评论

发布
暂无评论
发现更多内容

「Go框架」http请求处理流程: gin、beego等web框架是如何处理http请求的?

Go学堂

golang 开源 程序员 个人成长 12月月更

隐私计算之多方安全计算(MPC,Secure Multi-Party Computation)

京东科技开发者

大数据 隐私安全 多方安全 MPC OT

尚硅谷发布JDBC新版视频教程

小谷哥

支持API 9的Sample已上新,速来拿走

HarmonyOS开发者

HarmonyOS

老板要的物联网可视化大屏,我30分钟就搞定了

华为云开发者联盟

物联网 华为云 12 月 PK 榜

Java高手速成│编写你第一个数据库程序

TiAmo

JDBC 数据库· 12月月更

基于聚类算法的话术挖掘技术及在营销服场景的落地应用

中关村科金

人工智能 大数据 算法 对话机器人 技术实践

转转AB平台的设计与实现

转转技术团队

大数据 A/B 测试

深耕数字办公,华为云桌面怎样带来高效办公体验?

路过的憨憨

【2023】合肥市等保测评有哪些公司?地址在哪里?

行云管家

等级保护 等保测评 等保2.0 合肥

前端开发培训后可以从事哪些方面的工作

小谷哥

手游“Lord of Dragons Global”进军P2E市场

科技热闻

数据代码如何“产地直销”,做到持续集成持续发布?

数造万象

高可用软件什么意思?哪些高可用软件好用?

行云管家

高可用 双机热备 高可用软件

昇腾CANN:为你开启机器人开发的Buff 加成

华为云开发者联盟

人工智能 华为云 昇腾AI 12 月 PK 榜

那些专注小程序语法编译的跨端开发平台

FinFish

前端框架 跨端开发 跨端框架 前端开发框架 前端开发平台

开发者可以选择哪些小游戏分发平台?

FN0

小游戏 小游戏开发 小程序化

无魅友,不魅族!魅族大力推广魅友文化,用行动阐述何为用户共创

Geek_2d6073

DAG任务调度系统 Taier 演进之道,探究DataSourceX 模块

袋鼠云数栈

开源

国产ETL 星光不问赶路人 时我不待

weigeonlyyou

oracle Prometheus Clickhouse MySQL 数据库 InfluxDB Cluster

今明两天,eBPF 技术探索和 Intel Arch 两大技术 SIG 继续开讲 | 第 57-58 期

OpenAnolis小助手

开源 ebpf intel 龙蜥大讲堂 浪潮信息

大数据开发技术有好的培训机构吗

小谷哥

三个延伸打法,撑起华为云桌面的7年领跑

路过的憨憨

【5000字长文】从 S3 到 DataZone,亚马逊云科技用16年讲完一个数据的故事

亚马逊云科技 (Amazon Web Services)

亚马逊云科技 Builder 专栏

LED显示屏企业需要抓住直播的风口吗?

Dylan

LED显示屏 全彩LED显示屏 led显示屏厂家

学习大数据开发技术能参加培训吗?

小谷哥

安装 Azure CL 并生成 service principal 文件

HummerCloud

云计算 azure

Code Review到底在关注些什么?

孟君的编程札记

Java CodeReview

大咖说·阿里云教育|“网上浙大”数字化之路

大咖说

数字化 高校

DevSecOps 需要知道的十大 K8s 安全风险及建议

SEAL安全

k8s DevSecOps 12 月 PK 榜

web前端培训机构怎么选?

小谷哥

微服务部署面临的挑战_语言 & 开发_Mark Little_InfoQ精选文章