Netflix，亚马逊等公司都在其产品中采用了微服务的概念。微服务是软件行业中最热门的话题之一，许多组织都希望采用它们。并且，DevOps可以很好地与微服务配合使用。
但什么是微服务？组织为什么要采用它们？
为了理解它们，我们首先来看看单片软件。
在单片软件中，我们主要采用三层结构：
· 表示层
· 业务层
· 数据访问层
假设，传统的Web应用程序客户端（浏览器）发布请求。业务层执行业务逻辑，数据库收集/存储特定于应用程序的持久性数据，UI向用户显示数据。
但是，这种类型的系统存在一些问题。所有代码（表示，业务层和数据访问层）都在相同的代码库中维护。虽然从逻辑上讲，我们将服务划分为JMS服务和数据访问服务，但它们位于相同的代码库中并作为一个单元进行部署。
即使你创建了一个多模块项目，一个模块依赖于另一个模块，而且该模块在其类路径中需要依赖模块。虽然你使用的是分布式环境，但它在单个进程上下文下运行。
因此，在单个进程中，不同的服务相互通信。为此，每个应用程序容器中都需要所有工件及其所需的库(jars)。
假设JMS服务想要使用数据访问层。 JMS容器需要数据访问层jar和数据访问层所依赖的jar（第二级依赖项）。
这里是一些你所面临的问题。
问题1
无论是UI开发人员还是业务层开发人员，都在相同的代码库中提交，导致代码库逐渐增长，这使得管理效率非常低。假设一个开发人员只在JMS模块中工作，但他却必须将整个代码库拉到他的本地并配置整个模块，以便在本地服务器上运行它。但他应该只专注于JMS模块，不过目前的情况不允许这样做。
问题2
由于存在一个代码库并且模块彼此依赖，因此一个模块中的最小变化需要生成所有工件并且需要在分布式环境中的每个服务器池中进行部署。
假设在多模块项目中，JMS模块和业务模块依赖于数据访问模块。数据访问模块的简单更改意味着我们需要重新打包JMS模块和业务模块，并将它们部署在其服务器池中。
问题3
由于单片软件使用三层架构，因此三个跨职能团队参与开发功能。尽管三层架构允许职责分离，但从长远来看，边界被跨越，各层失去了流动性，变得僵化。
假设已经开发了库存管理功能。 UI，业务层和数据访问层都有自己的工作。但是每个人都希望控制主要业务部分，以便在出现缺陷时，他们可以解决这些问题并且不依赖于其他层的开发人员。由于这种竞争，这些界限最终被跨越，这导致了低效的架构。
问题4
在许多项目中，有开发团队和支持团队。开发团队只开发项目，在项目发布后，他们将其交给支持团队。我个人不支持这种文化。虽然在交接过程中发生了一些知识转移，但并不能解决问题。对于关键事件，支持团队必须从开发团队获得帮助，这会损害他们的可信度。
问题5
由于我们的系统是单一的，我们的团队管理也是如此。通常，我们基于层创建团队 - UI开发人员，后端开发人员，数据库程序员等。他们是各自领域的专家，但对其他层面却知之甚少。因此，当有一个关键的问题出现时，它涉及了每一层。不仅如此，还需要额外的时间来决定它是哪一层的问题，以及谁需要解决这个问题
Netflix和亚马逊通过一种称为微服务的解决方案来解决这些问题。
微服务架构告诉我们将产品或项目分解为独立服务，以便它可以仅在该级别进行部署和管理，而不依赖于其他服务。
看到这个定义后，脑海中浮现出一个明显的问题。我在什么基础上我将我的项目分解为独立服务？
许多人对微型服务有错误的认识。MicroServices并没有告诉你要根据这个层(如JMS、UI、日志记录等)来分解你的项目。
我们需要按功能细分。完整的功能可能包括UI，业务，日志记录，JMS，数据访问，JNDI查找服务等。
该函数不应是可除的，也不应依赖于其他功能。
因此，如果项目有库存、订单、计费、发货和UI购物车模块，我们可以将每个服务分解为一个独立的可部署模块。每个服务器都有自己的维护、监视、应用服务器和数据库。因此，对于微型服务，没有集中式数据库，每个模块都有自己的数据库。
它可以是关系数据库，也可以是NoSQL数据库。你可以根据模块选择。它创建了一个多语言持久性。
微型服务文化最重要的方面是，无论谁开发服务，管理服务都是团队的责任。这避免了切换概念和与其相关的问题。
微型服务的优势和缺点
优势1
在单片软件中，你只使用一种语言(比如Java)作为代码库。但是对于微服务，由于每个服务都是独立的，并且每个服务都是一个新项目，因此每个服务都可以用最适合需求的任何语言进行开发。
优势2
开发人员只专注于特定服务，因此代码库将非常小，开发人员将非常了解代码。
优势3
当一个服务需要与另一个服务进行通信时，他们可以通过API进行通信，特别是通过REST服务进行通信。 REST服务是通信的媒介，因此几乎没有变革。与SOA不同，微服务消息总线比ESB薄得多，后者执行大量转换，分类和路由。
优势4
没有集中式数据库。每个模块都有自己的模块，因此存在数据分散。你可以使用NoSQL或关系数据库，具体取决于模块，这将介绍我之前提到的多语言持久性。
很多人认为SOA和微服务是一回事。根据定义，它们看起来相同，但SOA用于通过ESB通信不同的系统，其中ESB负责管理数据，进行分类等。
但是微服务使用一个哑消息总线，它只将输入从一个服务传输到另一个服务，但是它的端点足够智能来执行上述任务。
当微服务通过REST进行通信时，转换范围非常小 - 只有一个服务通过API调用依赖于另一个服务。
但是MicroServices也有缺点
由于每个功能方面都是一个单独的服务，所以在一个大项目中，有许多服务。监视这些服务会增加开销。
不仅如此，当服务出现故障时，跟踪它可能是一项艰苦的工作。 服务调用彼此，因此跟踪路径和调试也很困难。
每个服务都会生成一个日志，因此没有中央日志监控。这是痛苦的事情，我们需要一个非常好的日志管理系统。
使用微服务，每个服务通过API /远程调用进行通信，这比使用单一软件的进程间通信调用具有更多的开销。
但是，尽管存在所有这些不利因素，微服务仍然真正地分离了责任。
原文标题《Why microservices？》
作者：Shamik Mitra
译者：lemon
不代表云加社区观点，更多详情请查看原文链接
