介绍

刚开始时，由于要求简略，所以应用程序既简略又小。 随着时间要求跟需求的下降，我们的应用程序显得越来越大，越来越复杂。 这造成将单片服务器开发跟布署为一个单元。 在某些程度上，微服务可以通过简略的应用程序回归基础，这些应用程序可以通过运用互相之间的API一起工作来满足现今对复杂性的需求。

什么是整体服务器？

与微服务相比，微服务最好被解释。 整体服务器 。 它们作为一个单元开发跟布署 。 对于Java，最终结果一般是单个WAR或JAR文件。 C ++ 、. Net，Scala跟许多其他编程语言只是这么。

大多数硬件开发的短暂历史都以我们开发的应用程序规模的不断降低为标识。 随着时间的溜走，我们将越来越多地添加至我们的应用程序中，从而不断提高他们的复杂性跟大小，并增加我们的开发，测试跟布署速率 。

随着时间的溜走，我们开始将应用程序界定为多个层：表示层，业务层，数据访问层等。这种分离比地理上更逻辑。 尽管开发显得容易一些，但每天修改或公布时，我们依然须要检测跟布署所有内容。 在企业环境中，拥有耗费数小时就能建立跟布署的应用程序并不稀少。 测试，尤其是回归测试，往往是一场恶梦，在这些状况下会持续数月之久。 随着时间的溜走，我们进行仅影响一个模块的修改的能力正在衰退。 分层的主要目的是让他们便于替换或升级。 这个承诺未曾真正实现。 在小型整体应用中更换零件几乎从来都不容易，而且没有风险。

扩展这些服务器意味着扩充整个应用程序，从而形成极其不平衡的资源运用。 如果我们还要更多的资源，即使难题是一个模块，我们也被迫在新服务器上复制所有内容。

什么是微服务？

微服务是一种构架跟开发由小服务组成的单个应用程序的方式。 了解微服务的关键是他们的独立性 。 彼此分别开发微端服务器，测试跟布署。 每个服务作为单独的进程运行。 不同微服务之间的惟一关系是通过他们公开的API来完成数据交换。 它们以某些形式承继了Unix / Linux中使用的大型程序跟管线的思想。 大多数Linux程序太小，并且会形成一些输出。 该输出可以作为键入传递给其他程序。 链接在一起时，这些程序可以执行特别复杂的操作。 它是由许多简略单元组合而成的复杂性。

微服务的关键方面是：

微服务的问题之一是决定何时使用他们。 最初，尽管应用程序依然太小，但是微服务企图解决的问题并不存在。 但是，一旦应用程序下降甚至可以提出微服务的理由，切换至另一种机制结构式样的费用可能会很大。 经验丰富的团队或许从一开始就使用微服务，因为它们晓得它们之后或许须要还清的技术债权比起一开始使用微服务要高昂得多。 通常，就像Netflix，eBay跟Amazon一样，整体式应用程序开始逐步向微服务发展。 新模块被开发为微服务，并与系统的其余部份集成。 一旦证明了自己的价值，现有的整体应用程序的一部分都会构建为微服务。

企业应用程序开发人员常常引发批评的一件事是数据储存的分散化。 尽管微服务可以使用集中式数据储存来工作（只需进行少量调整），但起码应当探求让该部份分散的选项。 将与这些服务相关的数据储存在单独的（分散式）存储中并将其全部打包至同一容器中的选择在许多状况下比将数据储存在集中式数据库中更好。 我们不建议仍然使用分散存储，而在设计微服务时考虑使用该选项。

缺点 营运跟布署复杂性提高

反对微服务的主要论据是操作跟布署复杂性的提高。 这种说法是正确的，但是因为有了相对较新的工具，它可以改善。 配置管理（CM）工具可以相对轻松地处理环境设置跟布署。 Docker对容器的运用大大提高了微服务或许导致的布署麻烦。 CM工具与Docker一起让我们能否轻松布署跟扩充微服务。 可以在文章连续布署：使用Ansible跟Docker推行中找到一个样例。