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

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等无服务器-计算技术来进一步简化微服务的开发和交付。有了这种无服务器架构，微服务应用程序将基本上变成短暂的功能的集合，每个功能都可以根据需要快速随意创建、更新、替换和删除。

未来挑战

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

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

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

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

• 故障、恢复和自我修复

• 组织文化和协调