[微服务] 演化历史与未来挑战

Microservices-The Journey So Far and Challenges Ahead

翻译,原文出处——IEEE SOFTWARE | PUBLISHED BY THE IEEE COMPUTER SOCIETY 2018

微软服务是软件服务设计,开发和交付的最新趋势:
1. 它们构成了一种软件和系统架构的方法,它建立在既定的模块化概念之上,但强调技术边界。 每个模块、每个微服务都作为一个小而独立的系统来实现和运行,通过一个良好定义的网络接口提供对其内部逻辑和数据的访问.
2. 这增加了软件敏捷性,因为每个微服务成为独立的开发,部署,运营, 版本控制和缩放。

与SOA架构的关系

  • 微服务是SOA的一个特定子类型。但是,尽管SOA倾向于强烈依赖诸如企业服务总线或其他类似重量级中间件的产品,但微服务仅依赖于轻量级技术。

  • 其次,SOA通常与Web服务协议,工具和格式(如SOAP,WSDL(Web服务描述语言)和WS- *标准系列)相关联。 相比之下,微服务通常依赖REST(Representational State Transfer)和HTTP4或其他被认为轻量级和本地化的Web开发格式。

  • 最后,SOA被看作是一个集成解决方案,而微服务通常被用来构建单独的软件应用程序。

微服务的好处

  • 交付速度更快:微服务通常采用轻量级容器技术打包并部署在云中,遵循行业验证的DevOps惯例,并由全自动化软件集成和交付机制支持。这样可以在多种执行环境中快速部署微服务(例如, 测试,分期和金丝雀版本),只需最低限度的集中管理

  • 可扩展性更好:单个微服务是开发部署与运行的最小单元,在运行时,服务可根据其特定要求进行不同的扩展,同时每个微服务都可以由不同团队开发,部署和运营,从而可以并行地引入新功能。

  • 具有更大的自主权:每个微服务都可以提供一个独立、受限的开发和运行时的决策单元,可以让团队自由选择编程语言或实施策略的任何其他方面。

微服务演化

由SOA演化而来,SOAP切换到REST,更轻量和简单的服务调用协议

技术角度

从2008年到2018年这十年间,有10个软件技术的“浪潮”。在“微服务”这个词被普遍采用之前,前五种技术浪潮已经存在——

  • 第一波包含轻量级容器技术(例如LXC和Docker),这些技术允许在运行时更有效地打包、部署和管理各个服务。

  • 第二波包括服务发现技术,它们让服务彼此通信而不明确地提及其网络位置。

  • 第三波包括监测技术(例如Graphite和Sensu),这些技术可以运行时监控和分析不同细节层次的微服务资源的行为。

  • 第四波包括容器编排技术(例如Mesos和Kubernetes),它们实现了容器分配和管理任务的自动化,抽象出底层的物理或虚拟基础架构。

  • 第五波包括延迟和容错通信库(例如Finagle和Hystrix),它们使服务能够更加高效和可靠地进行通信。

其他五个浪潮是为了响应微服务的日益普及而出现的——

  • 第六次浪潮包括持续交付技术(例如Ansible和Drone),它们提供通用集成解决方案,以自动化网络规模微服务生产环境中的DevOps实践。

  • 第七次浪潮包括混沌工程技术(例如Simian Army和Chaos Toolkit),它可以自动执行关键的全系统可靠性和安全测试技术,例如故障和攻击注入。

  • 第八个浪潮包含边车(sidecar)技术(例如Prana和Envoy),它封装了与通信相关的功能,如服务发现和使用协议特定和容错通信库,以便从服务开发人员中抽象出来。

  • 第九波包括的无服务器(serverless)计算技术(例如,AWS Lambda和OpenWhisk),该模型实现了FaaS云模型。交付生产更精细的服务功能或功能,而无需创建和管理(例如,应对不一致的流量模式)执行所需的基础设施资源的复杂性。

  • 第十波包括服务网格技术(例如,Linkerd和Istio),它们建立在边车技术基础之上,以提供完全集成的服务到服务通信监视和管理环境。

架构角度

微服务架构的四代更迭——

  • 第一代:单个服务使用轻量级容器包装,使用容器编排工具运行时部署和管理;但每个服务都要负责自己跟踪其他服务的位置并进行失败处理。

  • 第二代:引入服务发现和可重用的容错通信库,但通信库的语言限制了服务的编写语言。

  • 第三代:引入标准的服务代理/边车作为一个透明的服务中介。

  • 第四代:这个想法是利用最近的FaaS和AWS的Lambda等无服务器-计算技术来进一步简化微服务的开发和交付。有了这种无服务器架构,微服务应用程序将基本上变成短暂的功能的集合,每个功能都可以根据需要快速随意创建、更新、替换和删除。

未来挑战

  • 服务的模块化与重构:如何划分模块、分配职责、设计接口

  • 服务粒度:不同的项目团队对于微服务的大小规模意见不一致,缺乏统一的标准

  • 前端集成:通常是一个巨石的前台使用大量的后台的微服务体系,这导致所有单体体系结构的缺点依旧存在

  • 资源监控和管理:信息太多,无法做出及时的管理决策;如何定义一个准确的警告阈值、信息过滤——利用数据挖掘、控制理论和机器学习从历史事件中学习

  • 故障、恢复和自我修复

  • 组织文化和协调

猜你喜欢

转载自blog.csdn.net/Blanchedingding/article/details/81006371