编者语： 微服务，就是将单体（monolithic）代码剖析为易于维护的块，而这正是运维（devops）哲学的关键。或者说是基于不停扩展的业务而实现针对业务功效域的应用商业价值的快速交付或敏捷响应。那么如何认识明白微服务，或说微服务到底哪些价值特征点值得作为下一个软件架构的优先选项呢？那本篇文章，就是希望通过简明简要论述，促进你把微服务纳入下一个优选架构选项。
本文由牛旦课堂原创，版权归创作者所有，转载请注明泉源或私信联系。1 导语险些每个盘算机系统都市使用共享资源来执行多个任务，而盘算机编程的问题之一，就是执行这些任务的代码位之间应该需要有多精密才合适？一个越来越盛行的谜底就是微服务，——一个小而离散的功效块，它通过与其他微服务交互而建立更大的应用系统。
只管拥有这种离散组件的基本思想并不新鲜，但微服务的实现方式，使其成为两个现代基于云的应用法式的天然基础。微服务还与devops哲学相吻合，即后者勉励快速、连续地推出新功效。
2 微服务是个什么鬼？微服务(microservices)中的微(“micro”)意味着这些都是小型应用法式。有时这是对的，但更好的思考或明白方式是，它们应该只大到能做好一件特定的事情或解决一个特定的问题,这就足够了（或者这可看作为微服务上下文的“界限”）。
这个问题应该是观点性的，而不是技术性的。正如微软所说，“微服务应该围绕业务功效而设计，而不是像数据会见或消息通报这样的水平条理。”(Microservices should be designed around business capabilities, not horizontal layers such as data access or messaging.)它们通过相对稳定的api与其他微服务和外部用户通信，从而建立更大的应用法式。
因此，可以在不影响系统其余部门的情况下调整或彻底升级单个微服务的内部功效。这反过来又与devops团队寻求的运营方式有关:如果大型应用法式的特定功效被支解成离散的、独立的操作代码片段，那么就更容易实现devops的CI/CD(continuous integration and continuous delivery,连续集成和连续交付)价值哲学。
另外，界说良好的api使微服务易于实现自动化测试。3 微服务架构和单体架构 我们经常会听到人们用“微服务体系结构”或微服务架构来谈论微服务。这个短语不仅包罗微服务自己，还包罗用于治理和服务发现的组件，以及处置惩罚微服务与外部世界之间通信的API网关。
单体应用法式是微服务的对立面。对于所有代码都在一个庞大的二进制可执行文件中的应用法式来说，它是一种倒退。正如TechTarget解释的那样，单体应用法式很难扩展，也很难革新。
可是因为它是作为单一内聚应用法式构建的，所以它不需要像微服务架构那样有许多的治理事务。从这点讲，确实是有倒退之嫌。4 界限：如何界说微服务？让我们回首一下之前的“戒律”，即微服务应该做一件特定的事情。说起来容易，但在实践中，功效经常是相互交织的，绘制出分区比看上去要难题得多。
领域分析和领域驱动设计(Domain analysis & domain-driven design)是微服务的指导理论方法，可以资助我们将总体任务剖析成微服务可以解决的单个问题。在这个历程中，需要建立业务领域的抽象模型，并在这个历程中发现界限上下文，它将以特定方式把与相应领域交互的功效组合在一起而形成的微服务。例如，您可能有一个界限上下文用于运输，而另一个用于账目之用。
固然，现实中的一个物理工具，既有价钱也有需要去的地方，而界限上下文就是代表应用法式要思量这些工具以及与之交互的特定方式。每个微服务应该完全存在于单个界限上下文中，只管有些界限上下文可能包罗多个微服务——需要明确，微服务有单个焦点服务和流程服务组成。5 微服务与SOA架构及Web服务在这一点上，如果你是一名IT专业人员，而且已经在这个行业事情了一段时间，那么可能会认为这些内容听起来很熟悉。小型的单个法式协同事情的想法可能会让您想起SOA(service-oriented architecture，面向服务的体系结构)和Web服务，这两个盛行词来自二十一世纪令人兴奋的Web 2.0时代。
虽然从某种意义上说，世界上确实没有什么新工具，但这些观点和微服务之间存在着重要的区别。Datamation网站上有篇作甚微服务（https://www.datamation.com/cloud-computing/what-is-microservices.html）对这些差异有一个很好地细分，但这里有一个简短的版本概述如下: 在SOA面向服务的体系结构中，各个组件相对精密耦合，通常共享存储等资产，而且它们通过称为ESB（enterprise storage bus企业存储总线）的专用软件举行通信。微服务越发独立，共享的资源更少，而且通过更轻量的协议举行通信。
值得注意的是，微服务发生于SOA情况，有时被认为是SOA的一种，或者是观点的继续者。 Web服务是一组面向民众的功效，其他应用法式可以通过Web会见它;最盛行的例子可能是谷歌舆图，餐馆的网站可以嵌入它以为主顾提供偏向定位。这种毗连比您在microservices体系结构中看到的要松散得多。
6 微服务通讯 我们经常听到的关于微服务架构的一个口号是，它们应该具有“智能端点和哑管道”（smart endpoints & dumb pipes.）的特性。换句话说，微服务的目的应该是使用基本的和完善的通讯方法，而不是庞大的和精密集成方式。如上所述，这是微服务与SOA的另一个区别。
一般来说，微服务之间的通信应该是异步的(asynchronous)，因为代码线程不会被阻塞而来等候响应。(只管AMQP(Advanced Message Queuing Protocol，高级消息行列协议)等异步协议在微服务架构中也很常见，但使用HTTP等同步通信协议仍然很好。)这种松散耦合使得微服务架构在面临网络的单个组件或部门故障时越发灵活，这是一个关键的利益。
7 Microservices、Java、Spring Boot 与 Spring Cloud微服务的一些最初的事情泛起在Java社区,马丁·福勒(Martin Fowler)是早期的支持者。2012年在波兰举行的Java集会上有一个关于这个主题的最重要的早期陈诉，题目是“微服务—Java, Unix方式”（http://2012.33degree.org/talk/show/67）。它建议以此作为指导20世纪70年月第一批Unix应用法式开发的原则(编写只做一件事的法式并把它做好。
编写要一起事情的法式)，并也适用Java开发。这段历史的效果是，有许多Java框架允许您构建微服务。其中最盛行的是Spring Boot，它是专门为微服务设计的;Spring Cloud扩展了Spring Boot，顾名思义，它允许你将这些服务部署到云上。Spring的开发人员Pivotal Software提供了一个很好的教程，先容如何使用这些框架来开始微服务的开发。
8 微服务和容器: Docker, Kubernetes及更多在使微服务成为主流方面走得最远的底层技术是容器。容器类似于VM实例，但它不包罗整个自包罗的操作系统，容器只是一个独立的用户空间，它使用主机操作系统的内核，且在内核中执行的代码保持自包罗。
容器比VM实例小得多，而且很容易快速部署(当地或云中)，而且可以向上或向下旋转以匹配需求和可用资源。容器对微服务的吸引力是显而易见的:每个单独的微服务可以在自己的容器中运行，这大大淘汰了治理服务的开销。
大多数容器实现都具有互补的编配工具，这些工具可以实现自动部署、治理、扩展、联网和基于容器的应用法式可用性。小型、易于构建的微服务和易于部署的容器的联合使得运维devops哲学成为可能。
容器观点有几种实现，但现在最盛行的是Docker，它通常与Kubernetes一起作为编排平台。Spring虽然很盛行，但它是与Java平台绑定的。另一方面，基于容器的系统是多语言的:OS支持的任何编程语言都可以在容器中运行，这为法式员提供了更大的灵活性。实际上，微服务的一大优势在于，每个服务都可以用最合适的或者开发人员最喜欢的语言来编写。
实际上，只要服务的api保持稳定，就可以在不影响整个系统的情况下，用一种新的语言完全重新构建服务。DZone有一篇文章讨论了用于微服务的Spring Cloud与Kubernetes的优缺点。
9 微服务设计模式 无论使用哪种语言来开发微服务，都将面临其他开发人员以前遇到过的问题。设计模式是对盘算机科学中重复泛起的问题的形式化、抽象化的解决方案，其中许多是专门为微服务设计的。
Devopedia网站上有一个很棒的列表，包罗: 服务注册（Service Registry）:用于将客户端毗连到可用的微服务实例； 断路器（Circuit Breaker）:防止已失败或出故障的服务被重复挪用； 回退（Fallback）:用于为失败的服务提供替代方案； 跟踪服务（Sidecar）:为主容器提供辅助服务，例如用于日志记载、同步服务或监视； 适配器（Adapter）:尺度化或规范化主容器和外部世界之间的接口 ； 署理大使（Ambassador）:将主容器与外部世界毗连，例如将本机毗连署理到外部毗连。10 微服务和云: 华为、阿里、AWS 和 Azure如上所述，使用容器的优势之一是可以轻松地将其部署到云中，云中有灵活的盘算资源，因此可以最大限度地提高应用法式的效率。可以想象，主要的公共云供应商都希望你使用他们的平台来运行基于微服务的应用法式。
有关更多信息，请检察来自阿里云、华为、以及Amazon、Microsoft和谷歌的相关资源。关于选择微服务架构作为优选项相关内容就简要先容到这里。
另一篇可进一步阅读：我们为何要搞微服务架构？。
本文关键词：微,服务,你,下一个,软件,架构,的,优,选项,ob欧宝·体育app官方网站
本文来源：ob欧宝·体育app官方网站-www.czxyhjx.com
