就在短短几年前，微服务还只是一个新鲜事物。开发者谈起这种初露头角的应用架构所带来的各种可能性和机遇时，难掩兴奋之情。
如今，就连我们这些网络从业者也开始讨论微服务，因为正如Lightstep的最新研究所指出的，微服务已基本成为企业的主流选择。确实如此。在我们2018年的《应用交付现状》报告中，就连网络相关岗位的受访者也表示，希望通过容器提供应用服务。因此，上述Lightstep调查发现，91%的受访者正在使用或计划使用微服务，86%的受访者还预计微服务将在5年内成为默认选择，这并不令人意外。
这并不是说微服务不存在挑战。事实上，Lightstep调查中99%的受访者表示，他们在使用微服务时遇到了挑战。从调查反馈来看，可以合理地说，采用微服务后，几乎所有事情都会变得更加困难（有时成本也更高）。
调查显示，企业面临业务和运营方面的多项挑战，包括日志聚合成本上升（21%）、不知如何处理不断增加的数据（17%），以及难以排查问题（73%）。
然而，更令人担忧的是，调查发现：“在微服务环境中难以确定问题根本原因的受访者中，98%表示这会直接影响业务。”
这是其他领域也普遍提到的关键挑战之一。网络团队通常称之为“可见性”，而DevOps团队则称之为“可观测性”。
两者本质上描述的是相同的能力，即能够了解消息在客户端与服务之间通过网络往返传输时的情况。在容器环境中，由于涉及的服务范围广、规模大，实现这一点尤其具有挑战性。
对于传统的三层Web应用，需要跟踪3组日志和3个系统。采用微服务架构时，前端通常会使用一个API，而Web和移动客户端都可能调用该API，因此可能需要跟踪数十甚至数百个不同的服务。
扩展模式仍然相同，即通过克隆实例进行横向扩展，但容器环境中的规模要大得多。这就像打地鼠，只不过洞从10个增加到了100个。要确定任意一笔事务经过的路径，至少可以说并非易事，尤其是这条路径可能已经消失。毕竟，大多数容器环境的基本理念是快速失败并替换实例，而不是等待人工干预。
有几种方法可以应对这一挑战。首要方法是使用有助于跟踪和故障排除的检测机制。这种方法并不新鲜，但容器环境的易变性增加了实施难度。尽管如此，在运维人员排查错误或性能问题时，插入跟踪元素（例如带有唯一标识符的自定义HTTP标头）仍能提供很大帮助。原生容器扩缩容方案通常不具备这项能力，但服务网格正在着手解决这一问题，并将其纳入自身提供的功能。
其次，可以隔离出现故障的微服务，让运维和开发人员检查系统发生故障时的状态。隔离实际上是将故障容器从活动环境中移除，使调用不再发送到该容器，同时保持其运行，以便进行分析和检查。
虽然没有一劳永逸的解决方案，但在基于微服务的部署中跟踪和隔离容器，有助于大幅缩短平均解决时间（MTTR），并降低对业务的影响。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。