编者语：
微服务，就是将单体（monolithic）代码分解为易于维护的块，而这正是运维（devops）哲学的关键。或者说是基于不断扩展的业务而实现针对业务功能域的应用商业价值的快速交付或敏捷响应。
那么如何认识理解微服务，或说微服务到底哪些价值特征点值得作为下一个软件架构的优先选项呢？那本篇文章，就是希望通过简明扼要阐述，促进你把微服务纳入下一个优选架构选项。
本文由牛旦课堂原创，版权归创作者所有，转载请注明来源或私信联系。
几乎每个计算机系统都会使用共享资源来执行多个任务，而计算机编程的问题之一，就是执行这些任务的代码位之间应该需要有多紧密才合适？一个越来越流行的答案就是微服务，——一个小而离散的功能块，它通过与其他微服务交互而创建更大的应用系统。
尽管拥有这种离散组件的基本思想并不新鲜，但微服务的实现方式，使其成为两个现代基于云的应用程序的天然基础。微服务还与devops哲学相吻合，即后者鼓励快速、持续地推出新功能。
微服务(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使微服务易于实现自动化测试。
我们经常会听到人们用“微服务体系结构”或微服务架构来谈论微服务。这个短语不仅包括微服务本身，还包括用于管理和服务发现的组件，以及处理微服务与外部世界之间通信的API网关。
单体应用程序是微服务的对立面。对于所有代码都在一个巨大的二进制可执行文件中的应用程序来说，它是一种倒退。正如TechTarget解释的那样，单体应用程序很难扩展，也很难改进。但是因为它是作为单一内聚应用程序构建的，所以它不需要像微服务架构那样有许多的管理事务。从这点讲，确实是有倒退之嫌。
让我们回顾一下之前的“戒律”，即微服务应该做一件特定的事情。说起来容易，但在实践中，功能常常是相互交织的，绘制出分区比看上去要困难得多。领域分析和领域驱动设计(Domain analysis & domain-driven design)是微服务的指导理论方法，可以帮助我们将总体任务分解成微服务可以解决的单个问题。在这个过程中，需要创建业务领域的抽象模型，并在这个过程中发现边界上下文，它将以特定方式把与相应领域交互的功能组合在一起而形成的微服务。
例如，您可能有一个边界上下文用于运输，而另一个用于账目之用。当然，现实中的一个物理对象，既有价格也有需要去的地方，而边界上下文就是代表应用程序要考虑这些对象以及与之交互的特定方式。每个微服务应该完全存在于单个边界上下文中，尽管有些边界上下文可能包含多个微服务——需要明白，微服务有单个核心服务和流程服务构成。
在这一点上，如果你是一名IT专业人员，并且已经在这个行业工作了一段时间，那么可能会认为这些内容听起来很熟悉。小型的单个程序协同工作的想法可能会让您想起SOA(service-oriented architecture，面向服务的体系结构)和Web服务，这两个流行词来自二十一世纪令人兴奋的Web 2.0时代。虽然从某种意义上说，世界上确实没有什么新东西，但这些概念和微服务之间存在着重要的区别。Datamation网站上有篇何为微服务（https://www.datamation.com/cloud-computing/what-is-microservices.html）对这些差异有一个很好地细分，但这里有一个简短的版本概述如下:
我们经常听到的关于微服务架构的一个口号是，它们应该具有“智能端点和哑管道”（smart endpoints & dumb pipes.）的特性。换句话说，微服务的目标应该是使用基本的和完善的通讯方法，而不是复杂的和紧密集成方式。如上所述，这是微服务与SOA的另一个区别。
一般来说，微服务之间的通信应该是异步的(asynchronous)，因为代码线程不会被阻塞而来等待响应。(尽管AMQP(Advanced Message Queuing Protocol，高级消息队列协议)等异步协议在微服务架构中也很常见，但使用HTTP等同步通信协议仍然很好。)这种松散耦合使得微服务架构在面对网络的单个组件或部分故障时更加灵活，这是一个关键的好处。
微服务的一些最初的工作出现在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提供了一个很好的教程，介绍如何使用这些框架来开始微服务的开发。
在使微服务成为主流方面走得最远的底层技术是容器。容器类似于VM实例，但它不包括整个自包含的操作系统，容器只是一个独立的用户空间，它利用主机操作系统的内核，且在内核中执行的代码保持自包含。容器比VM实例小得多，而且很容易快速部署(本地或云中)，并且可以向上或向下旋转以匹配需求和可用资源。
容器对微服务的吸引力是显而易见的:每个单独的微服务可以在自己的容器中运行，这大大减少了管理服务的开销。大多数容器实现都具有互补的编配工具，这些工具可以实现自动部署、管理、扩展、联网和基于容器的应用程序可用性。小型、易于构建的微服务和易于部署的容器的结合使得运维devops哲学成为可能。容器概念有几种实现，但目前最流行的是Docker，它通常与Kubernetes一起作为编排平台。
Spring虽然很流行，但它是与Java平台绑定的。另一方面，基于容器的系统是多语言的:OS支持的任何编程语言都可以在容器中运行，这为程序员提供了更大的灵活性。实际上，微服务的一大优势在于，每个服务都可以用最合适的或者开发人员最喜欢的语言来编写。实际上，只要服务的api保持稳定，就可以在不影响整个系统的情况下，用一种新的语言完全重新构建服务。DZone有一篇文章讨论了用于微服务的Spring Cloud与Kubernetes的优缺点。
无论使用哪种语言来开发微服务，都将面临其他开发人员以前遇到过的问题。设计模式是对计算机科学中重复出现的问题的形式化、抽象化的解决方案，其中许多是专门为微服务设计的。Devopedia网站上有一个很棒的列表，包括:
如上所述，使用容器的优势之一是可以轻松地将其部署到云中，云中有灵活的计算资源，因此可以最大限度地提高应用程序的效率。可以想象，主要的公共云供应商都希望你使用他们的平台来运行基于微服务的应用程序。有关更多信息，请查看来自阿里云、华为、腾讯以及Amazon、Microsoft和谷歌的相关资源。
关于选择微服务架构作为优选项相关内容就简要介绍到这里。
京公网安备 11010802035086号