- 中文名
- 微服务
- 外文名
- microservice
- 所属学科
- 计算机科学
微服务和SOA之间的差异可能不太清楚。虽然可以在微服务和SOA之间形成技术对比，尤其是围绕企业服务总线（ESB）的作用，但将差异视为范围之一更容易。SOA是企业范围内的一项工作，旨在标准化所有服务之间相互交流和集成的方式，而微服务体系结构则是特定于应用程序的。
微服务在管理人员和项目负责人中至少与在开发人员中一样受欢迎。这是微服务的较不寻常的特征之一，因为架构热情通常是为实际工程师保留的。这样做的原因是微服务更好地反映了许多业务主管想要组建和运行其团队以及开发流程的方式。换句话说，微服务是一种架构模型，可以更好地促进所需的运营模型。
微服务的最重要的和棵懂夜单一特征可能是订腿，由于服务较小且可独立部署，因此不再需要繁琐的行动才能更改应用程序钻探她中的一行文字。
但是，速度并不是以这种方式设计服务的唯一价值。一种常见的新兴组织模型是将跨职能的团队聚集在业务问题，服务或产品上。微服务模型非常适合这种趋势，因为它使组织能够围绕一项服务或一组服务创建跨职能的小型团队，并使它们以敏捷的方式运作。
在传统的n层体系结构模式中，应用程序通常共享一个公共堆栈，而大型关系数据库支持整个应用程序。这种方法有几个明显的缺点-最主要的缺点是，即使对于某些元素有一个清晰，更好的工具，应用程序的每个组件也必须共享一个公共的堆栈，数据模型和数据库。它造成了糟糕的体系结构，并且使开发人员感到沮丧，他们不断意识到可以使用更好，更有效的方式来构建这些组件。
相比之下，在微服务模型中，组件是独立部署的，并通过REST，事件流和消息代理的某种组合进行通信-因此，可以针对该服务优化每个单独服务的堆栈。技术一直在炒阀嫌变化，由多个较小的服务组成的应用程牛灶葛序随着更理想的技术的发展而变得更容易且成劝辨本更低。
使用微服务，可以单独部署敬迁迎单个服务，但是也可以单独扩展它们。由此带来的好处是显而易龙愚见的：如果正确完成，微服务比单片应用程序所需的基础结构要少，因为微服务仅支持对需要它的组件进行精确缩放，而对于单片应用程序则不需要整个应用程序。
微服务的关键要素之一是它通常很小。（没有任意数量的代码来确定某项内容是否为微服务，但名称中恰好有“微”字。）
当Docker的容器技术迎来了2013年，它也推出了计算模型，将成为微服务最密切相关。由于单个容器没有自己操作系统的开销，因此它们比传统虚拟机更小，更轻，并且可以更快地上下旋转，从而使其与微服务架构中的更小，更轻便的服务完美匹配。
随着服务和容器的激增，对大型容器进行编排和管理很快成为关键挑战之一。Kubernetes已经成为世界上最受欢迎的容器编排 技术之一，因为它做得很好。
微服务通常通过API进行通信，尤其是在首次建立状态时。虽然确实可以实现客户端和服务之间的直接通信，但API网关通常是有用的中介层，尤其是随着应用程序中服务数量的不断增长。API网关通过路由请求，将请求散布到多个服务中并提供额外的安全性和身份验证，充当客户端的反向代理。
相反，必须将建立状态的API调用与消息传递或事件流耦合在一起，以便服务可以广播状态更改，而其他相关方可以侦听这些更改并相应地进行调整。这项工作可能最适合于通用消息代理，但是在某些情况下，事件流传输平台（例如Apache Kafka）可能是一个很好的选择。
无服务器架构将某些核心云和微服务模式纳入其逻辑结论。在无服务器的情况下，执行单元不仅是一个小型服务，而且是一个功能，通常只能是几行代码。无服务器功能与微服务之间的界线模糊，但通常认为功能甚至比微服务小。
无服务器架构和功能即服务（FaaS）平台与微服务共享相似性的地方在于，它们都对创建更小的部署单位以及根据需求进行精确扩展感兴趣。
- 后端到前端（BFF，Backend for Frontend）模式： 此模式在用户体验和体验调用的资源之间插入一层。例如，在台式机上使用的应用与移动设备的屏幕大小，显示和性能限制不同。BFF模式允许开发人员使用该接口的最佳选项来为每个用户界面创建和支持一种后端类型，而不是尝试支持可与任何接口一起使用但可能会对前端性能产生负面影响的通用后端。
- 实体和聚合模式： 实体是通过其身份区分的对象。例如，在电子商务站点上，可以通过产品名称，类型和价格来区分“产品”对象。集合是一组应视为一个单位的相关实体的集合。因此，对于电子商务站点，“订单”将是买方订购的产品（实体）的集合（集合）。这些模式用于以有意义的方式对数据进行分类。
- 服务发现模式： 这些帮助应用程序和服务彼此查找。在微服务架构中，服务实例由于扩展，升级，服务故障甚至服务终止而动态变化。这些模式提供了发现机制来应对这种瞬变。负载平衡可以通过将运行状况检查和服务故障用作重新平衡流量的触发器来使用服务发现模式。
- 适配器微服务模式： 以旅行到另一个国家时使用的插头适配器的方式来思考适配器模式。适配器模式的目的是帮助转换不兼容的类或对象之间的关系。依赖第三方API的应用程序可能需要使用适配器模式，以确保该应用程序和API可以通信。
- Strangler应用程序模式： 这些模式有助于管理将整体应用程序重构为微服务应用程序。多彩的名称是指葡萄（微服务）随着时间的流逝缓慢地追赶和勒死一棵树（单片应用程序）。
尽管有许多很好地完成微服务的模式，但也有相当数量的模式可以使任何开发团队迅速陷入困境。其中一些（表述为微服务“不要”）如下：
- 微服务的第一条规则是，不要构建微服务：更准确地说，不要从微服务开始。一旦应用程序变得太大和笨拙而无法轻松更新和维护，微服务就是一种管理复杂性的方法。仅当感到整体的痛苦和复杂性开始蔓延时，才值得考虑如何将应用程序重构为较小的服务。
- 不要在没有DevOps或云服务的情况下进行微服务：构建微服务意味着构建分布式系统，并且分布式系统很难（如果做出选择，使它们变得更加困难，它们就特别困难）。尝试在没有a（适当的部署和监控自动化或b）托管的云服务来支持庞大的异构基础架构的情况下进行微服务正在引起很多不必要的麻烦。为自己省去麻烦，以便可以花时间担心状态。
- 不要通过使它们变得太小来制造太多的微服务：如果对微服务中的“微”概念走得太远，那么很容易发现自己的开销和复杂性超过了微服务体系结构的整体收益。最好倾向于大型服务，然后仅在它们开始发展微服务需要解决的特征时才将它们分开—即，部署变更变得越来越困难，通用数据模型变得过于复杂，或者其中的不同部分服务具有不同的负载/规模要求。
- 不要将微服务转变为SOA：由于微服务和面向服务的体系结构（SOA）在最基本的层次上都对构建可被其他应用程序使用的可重用的单个组件感兴趣，因此它们经常相互融合。微服务与SOA之间的区别在于，微服务项目通常涉及重构应用程序，因此更易于管理，而SOA则关注于改变IT服务在企业范围内的工作方式。演变为SOA项目的微服务项目可能会在自身的负担下崩溃。
- 不要尝试成为Netflix：在构建和管理占所有Internet流量三分之一的应用程序时，Netflix是微服务体系结构的早期先驱之一。这是一种完美的风暴，需要他们构建大量的自定义代码和普通应用程序不需要的服务。从可以应付的步调开始，避免复杂性并使用尽可能多的现成工具，会变得更好。
