几乎每个计算机系统都使用共享资源执行多个任务，计算机编程的一个问题是执行这些任务的代码位应该如何紧密地绑定在一起。一个越来越流行的答案是微服务的概念- - - - - -一个小的、离散的功能块，它与其他微服务交互以创建一个更大的系统。
尽管拥有这种离散组件的基本思想并不新鲜，但微服务的实现方式使它们成为现代基于云的应用程序的天然基础。微服务还与devops哲学相吻合，后者鼓励快速、持续地推出新功能。
什么是微服务?
微服务中的“微”意味着这些是小型应用程序。这有时是对的，但更好的思考方式是，他们应该只做一件特定的事情或解决一个特定的问题所需的那么大。这个问题应该是概念性的，而不是技术性的。作为微软说，“微服务应该围绕业务功能进行设计，而不是数据访问或消息传递等水平层。”它们通过相对稳定的api与其他微服务和外部用户通信，从而创建更大的应用程序。
因此，单个微服务的内部功能可以在不影响系统其他部分的情况下进行调整或彻底升级。这反过来又与devops团队寻求的操作方式有关:如果大型应用程序的特定功能被分割成离散的、独立操作的代码段，那么就更容易实现CI/CD (持续集成和持续交付)。此外，定义良好的api使微服务易于自动测试。
微服务架构vs.单片架构
你会经常听到有人用“微服务架构”来谈论微服务。”这个短语不仅包含微服务本身，而且用于管理和服务发现的组件，以及处理微服务与外部世界之间通信的API网关。
“单片应用”与微服务相反。这是一个retronym对于所有代码都在一个大型二进制可执行文件中的应用程序。正如TechTarget所解释的，单片应用程序是难以扩大规模，也难以改进。但是因为它是作为一个单一的内聚应用程序构建的，所以它不需要像微服务架构那样多的管理。
有限概念:如何定义微服务
让我们暂时回到我们之前的戒律，即微服务应该做一件特定的事情。这说起来容易，但在实践中，功能往往是交织在一起的，划分起来比看起来要难。领域分析和领域驱动设计是一种理论方法，可以帮助你把你的大任务分解成微服务可以解决的单个问题。在此过程中，概述了一个微软的一系列具有启发性的博文，您将创建业务领域的抽象模型，并在此过程中发现有界上下文，将以特定方式与世界交互的功能组合在一起。
例如，您可能有一个绑定上下文用于运输，另一个绑定上下文用于帐户。当然，现实世界的物理对象既有价格，也有它需要去的地方，但是有界上下文表示应用程序思考这些对象并与之交互的特定方式。每个微服务都应该完全存在于单个限定上下文中，尽管一些限定上下文可能包含多个微服务。
微服务、面向服务的体系结构和Web服务
在这一点上，如果您是一个在这个行业工作了一段时间的IT专业人士，您可能会认为这听起来很熟悉。小型单独程序一起工作的想法可能会使您想起SOA(面向服务的体系结构)和Web服务，这两个词来自21世纪令人兴奋的Web 2.0时代。虽然在某种意义上，太阳底下没有什么新鲜事物，但这些概念和微服务之间还是有重要区别的。数据化可以很好地分解差异，但这里有一个简短的版本:
- 在面向服务的体系结构中，各个组件相对紧密耦合，通常共享存储等资产，它们通过称为企业存储总线的专用软件进行通信。微服务更加独立，共享更少的资源，并通过更轻量级的协议进行通信。值得注意的是，微服务产生于SOA环境，有时被认为是SOA的一种，或者是SOA概念的继承者。
- Web服务是一组面向公众的功能，其他应用程序可以通过Web访问这些功能;最常见的例子可能是谷歌地图，餐馆的网站可以嵌入它，为顾客提供方向。这是一个比你在微服务架构中看到的松散得多的连接。
Microservices沟通
关于微服务架构，你经常听到的一个流行语是，它们应该具有“智能端点和哑管道换句话说，微服务的目标应该是使用基本和完善的通信方法，而不是复杂和紧密的集成。如上所述，这是微服务与SOA的另一个区别。
一般来说，微服务之间的通信应该是异步，从某种意义上说，代码线程不会阻塞等待响应。(尽管AMQP(高级消息队列协议)等异步协议在微服务体系结构中也很常见，但使用HTTP等同步通信协议还是可以的。)这种松耦合使微服务架构在面对网络的单个组件或部分故障时更加灵活，这是一个关键的好处。
微服务，Java, Spring引导和Spring云
一些关于微服务的最初工作出现在Java社区;马丁是早期的支持者。2012年在波兰举行的Java会议上有一个关于这个主题的最重要的早期演讲，题为“微服务——Java, Unix之路它建议应用指导20世纪70年代第一个Unix应用程序开发的原则(“编写只做一件事并把它做好的程序。编写程序一起工作”)到Java开发。
由于这段历史，有很多Java框架使您能够构建微服务。其中最流行的是Spring Boot，它是专门为微服务设计的;Boot由Spring Cloud扩展，顾名思义，它允许您将这些服务也部署到云中。Pivotal Software, Spring的开发商，有一个使用这些框架开始微服务开发的很好的教程。
微服务和容器:Docker、Kubernetes等等
使微服务成为主流的底层技术是容器。容器类似于虚拟机实例，但是容器不包括一个完整的自包含的操作系统，容器只是一个隔离的用户空间，它利用主机操作系统的内核，但在其他方面保持代码在其中自包含地执行。容器比VM实例小得多，易于在本地或云中快速部署，并且可以向上或向下旋转以匹配需求和可用资源。
容器对微服务的吸引力应该是显而易见的:每个单独的微服务都可以在自己的容器中运行，这大大减少了管理服务的开销。大多数容器实现都有互补的编排工具，这些工具可以自动化基于容器的应用程序的部署、管理、扩展、联网和可用性。它是小型、易于构建的微服务和易于部署的容器的组合使devops哲学成为可能。容器概念有几种实现，但到目前为止最流行的是码头工人，通常与Kubernetes作为编排平台。
Spring虽然很流行，但它与Java平台绑定在一起。另一方面，基于容器的系统是多语言的:操作系统支持的任何编程语言都可以在容器中运行，这为程序员提供了更大的灵活性。事实上，微服务的一大优势是，每个单独的服务都可以用任何最有意义或开发人员最熟悉的语言来编写。实际上，只要服务的api保持稳定，就可以完全用一种新语言重新构建服务，而不会影响整个系统。DZone有一篇文章讨论Spring Cloud vs. Kubernetes的利弊microservices。
微服务设计模式
无论您使用何种语言来开发微服务，都将面临其他开发人员以前遇到过的问题。设计模式是对计算机科学中反复出现的问题的形式化、抽象的解决方案，其中许多模式是专门针对微服务的。Devopedia有一个很棒的列表，包括:
- 服务注册表:用于连接客户端到可用的微服务实例
- 断路器:用于防止失败的服务被重复调用
- 后备方案:为失败的服务提供替代方案
- Sidecar:用于向主容器提供辅助服务，例如日志记录、同步服务或监视
- 适配器:使主容器与外部世界之间的接口标准化或规范化
- 大使:将主容器连接到外部世界，例如将本地主机连接代理到外部连接
微服务和云：AWS和Azure
如上所述，使用容器的优点之一是可以轻松地将它们部署到云中，在云中可以使用灵活的计算资源，因此可以最大限度地提高应用程序的效率。正如你所想象的，主要的公共云供应商都渴望你使用他们的平台来运行基于微服务的应用程序。有关更多信息，请查看亚马逊，微软,谷歌。