几乎每个计算机系统都使用共享资源来执行多个任务，并且计算机编程的问题之一是，执行这些任务的代码段应该紧密地联系在一起。 一种日益流行的答案是微服务的概念-的功能，与其他微服务交互，以创建一个更大的系统分散小块。
尽管拥有这样的离散组件的基本思想并不是什么新鲜事物，但是微服务的实现方式使它们成为现代基于云的应用程序的自然基础。 微服务还与devops理念相吻合，后者鼓励快速，连续地推出新功能。
什么是微服务？
微服务中的“微”意味着它们是小型应用程序。 有时是正确的，但考虑它们的更好方法是，它们应仅做一件特定的事情或解决特定的问题所需的大小。 这个问题应该是概念性的，而不是技术性的。 就像微软所说的那样 ，“微服务应该围绕业务功能设计，而不是像数据访问或消息传递这样的水平层。” 它们通过相对稳定的API与其他微服务和外部用户进行通信，以创建更大的应用程序。
因此，可以微调或彻底升级单个微服务的内部功能，而不会影响系统的其余部分。 反过来，这与devop商店的工作方式有关：如果将大型应用程序的特定功能细分为离散的，独立操作的代码段，则更容易实现CI / CD的devops理念（ 持续集成和连续交付） 。 此外，定义明确的API使微服务易于自动测试。
微服务架构与单片架构
您经常会听到有关“微服务架构”的微服务讨论。 这个词不仅包括微服务本身，还包括管理和服务发现的组件 ，以及处理微服务与外界之间通信的API网关。
“单一应用程序”与微服务相反。 对于所有代码都在一个大的二进制可执行文件中的应用程序，它是一个回顾 。 正如TechTarget解释的那样，单片应用程序更难扩展和改进 。 但是，由于它是作为单个内聚应用程序构建的，因此不需要像微服务体系结构那样多的管理。
有界概念：如何定义微服务
让我们备份一下我们先前的命令，即微服务应该做一件事。 这说起来很容易，但是在实践中，功能通常是交织在一起的，并且绘制分区要比看起来困难。 域分析和域驱动设计是理论方法，可以帮助您将大任务分解为微服务可以解决的单个问题。 在此过程中，如Microsoft一系列精彩的博客文章所述 ，您将创建业务领域的抽象模型，并在此过程中发现有限的上下文，这些上下文将以特定方式与世界交互的功能组合在一起。
例如，您可能有一个运输的有界上下文，而有一个帐户的有界上下文。 当然，现实世界中的物理对象具有价格和需要去的地方，但是有限的上下文表示您的应用程序思考这些对象并与之交互的特定方式。 每个微服务应完全存在于单个有界上下文中，尽管某些有界上下文可能包含多个微服务。
微服务与面向服务的体系结构与Web服务
在这一点上，如果您是在该行业工作了一段时间的IT专业人员，您可能会觉得其中很多听起来很熟悉。 小型个体程序协同工作的想法可能使您想起SOA（面向服务的体系结构）和Web服务，这是2000年代令人兴奋的Web 2.0时代的两个时髦术语。 虽然从某种意义上说，在阳光下确实没有什么新鲜事物，但是这些概念与微服务之间存在重要的区别。 Datamation对这些差异进行了很好的分类 ，但是这是一个简短的版本：
- 在面向服务的体系结构中，各个组件相对紧密地耦合在一起，通常共享诸如存储之类的资产，它们通过称为企业存储总线的专用软件进行通信。 微服务更加独立，共享更少的资源，并通过更轻量级的协议进行通信。 值得注意的是，微服务起源于SOA环境，有时被认为是一种SOA，或者是该概念的继承者。
- Web服务是其他应用程序可以通过Web访问的一组公共功能。 可能最流行的例子是Google Maps，餐厅的网站可以嵌入该地图以为顾客提供指导。 这种连接比您在微服务体系结构中看到的宽松得多。
微服务通信
您经常会听到一个关于微服务架构的流行语是它们应该具有“ 智能端点和哑管道 ”的特征。 换句话说，微服务应该旨在使用基本的和公认的通信方法，而不是复杂而紧密的集成。 如前所述，这是将微服务与SOA区别开的另一件事。
通常，微服务之间的通信应该是异步的 ，从某种意义上说，代码线程不会阻塞等待响应。 （尽管诸如微服务架构中的异步协议（如AMQP（高级消息队列协议）也很常见），使用HTTP之类的同步通信协议还是可以的。）这种松散的耦合使微服务架构在出现故障时更加灵活。单个组件或网络的一部分，这是一个关键优势。
微服务，Java，Spring Boot和Spring Cloud
微服务的一些最初工作出现在Java社区。 马丁·福勒 （ Martin Fowler ）是早期的拥护者。 2012年在波兰举行的Java会议上，有关该主题的最重要的早期演讲之一是“ 微服务-Java，Unix之路” 。它建议采用指导1970年代第一个Unix应用程序开发的原则（“写做一件事情并做得很好的程序。编写可协同工作的程序”）进行Java开发。
由于这段历史，大量的Java框架使您能够构建微服务。 最受欢迎的之一是Spring Boot，它是专门为微服务设计的。 引导由Spring Cloud扩展，顾名思义，它还允许您将这些服务也部署到云中。 Spring的开发者Pivotal Software提供了一个很好的教程，介绍如何使用这些框架进行微服务开发 。
微服务和容器：Docker，Kubernetes等
使微服务成为主流的最底层技术是容器。 容器类似于VM实例，但是容器不包括整个独立的OS，而是仅隔离的用户空间，该空间利用主机操作系统的内核，但在其内部使代码保持独立。 容器比VM实例小得多，并且易于在本地或云中快速部署，并且可以根据需要和可用资源进行旋转或向下旋转。
容器对微服务的吸引力应该显而易见：每个单独的微服务都可以在自己的容器中运行，这大大减少了管理服务的开销。 大多数容器实现具有互补的编排工具，这些工具可自动执行基于容器的应用程序的部署，管理，扩展，联网和可用性。 小型，易于构建的微服务和易于部署的容器的结合， 使devops理念成为可能 。 容器概念有几种实现方式，但是到目前为止，最受欢迎的是Docker ，它通常与Kubernetes配合使用，成为一个编排平台。
Spring虽然很流行，但它与Java平台相关。 另一方面，基于容器的系统是多语言的：OS支持的任何编程语言都可以在容器中运行，这为程序员提供了更大的灵活性。 确实，微服务的一大优势在于，每个单独的服务都可以用最有意义的语言编写，也可以让开发人员最满意的语言编写。 实际上，只要服务的API保持稳定，就可以用一种新的语言完全重建该服务，而不会影响整个系统。 DZone的一篇文章讨论了Spring Cloud与Kubernetes在微服务方面的优缺点 。
微服务设计模式
无论您使用哪种语言开发微服务，都将面临其他开发人员之前遇到的问题。 设计模式是形式化的，抽象的解决方案，用于解决计算机科学中反复出现的问题，其中许多模式专门用于微服务。 Devopedia有一个不错的清单 ，其中包括：
- 服务注册表：用于将客户端连接到可用的微服务实例
- 断路器：防止重复调用失败的服务
- 后备：用于提供替代失败服务的方法
- 边车：用于为主容器提供辅助服务，例如用于日志记录，同步服务或监视
- 适配器：标准化或规范主容器与外部世界之间的接口
- 大使：将主容器连接到外部世界，例如将localhost连接代理到外部连接
微服务和云 ： AWS和Azure
如上所述，使用容器的优点之一是可以轻松地将它们部署到可使用灵活计算资源的云中，从而可以最大程度地提高应用程序的效率。 您可能会想到，主要的公共云供应商都渴望您使用他们的平台来运行基于微服务的应用程序。 有关更多信息，请查看Amazon ， Microsoft和Google的资源。
397
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
