MicroServices这些天是软件开发圈中的热门话题。出于一些非常好的原因。
简单地说，构建企业应用程序的传统方法—使用单片方法- 当应用程序变得更大且更复杂时，哈斯变得有问题。因此，开发人员正在转向微服务器软件开发架构，其中应用程序被构造为松散耦合服务的集合。这使得它们更容易构建，更重要的是更容易扩展和缩放。
让我们进一步了解微服务方法与单片方法的不同之处，并分析它们的相对优缺点。
巨石:我们曾经的样子
传统上，软件开发人员创建的是大型、单片的应用程序。一个单一的庞然大物将包含所有的代码所有业务活动执行了申请。当然，随着申请的要求，整数所以整体也是如此。
以下是从单片应用开始的图。您编写了一个简单的应用程序，由单个团队开发和管理。
但是如果您的申请结果成功，会发生什么？用户喜欢它并开始依赖它。交通急剧增加。而且几乎不可避免地，用户请求改进和其他功能，因此更多的开发人员被绳索才能在越来越多的应用程序上工作。在长时间之前，您的应用程序看起来更像：
您的一次简单的应用程序变得越来越大而复杂。多个独立的开发团队正在同时处理它。
但这些所谓的独立团队实际上根本就不独立。他们同时在相同的代码库上工作，同时更改相同的代码部分。
当你有五个独立的开发团队在开发一个应用程序时相互重叠时会发生什么?几乎不可能知道谁在做什么。代码变更发生碰撞。代码质量以及应用程序质量和可用性都会受到影响。对于单个开发团队来说，在不计算对其他团队的影响的情况下进行更改变得越来越困难，而且团队可能会忽视他们的代码如何与其他团队不兼容，以及其他问题。这通常会导致更慢、更不可靠的应用程序，更不用说越来越长的开发计划。
这一反应不仅仅是技术：如果它是对业务的重要应用，开发延误，糟糕的应用程序性能，崩溃最终可能最终成本为您的公司客户和金钱。
幸运的是，这种情况并非不可避免。您可以重新构建和构建应用程序以实现可伸缩性和您公司的需求，而不是反对他们。使用现代的基于微服务的应用程序架构是一种越来越流行的技术，用于构建可以扩展的应用程序，而无需在单片渣土中归因于您的组织。
微服务：一个底漆
那么微服架构究竟是什么？根据马丁微服务体系结构由“围绕业务能力、自动化部署、端点智能以及语言和数据的分散控制”组织的“独立可部署的服务套件”组成。
微服务架构背后的主要思想是，当应用程序被分解成更小的部分无缝地工作时，它更容易构建和维护。在使用微服务时，您将软件功能隔离到多个独立的模块中，这些模块分别负责执行精确定义的独立任务。这些模块通过简单的、通用的应用程序编程接口(api)相互通信。
使用微服务构建的应用程序具有某些特征。特别是,他们:
- 分段为多个模块化，松散耦合的组件，每个组件执行离散函数
- 是否构建了与业务功能一致的单个功能
- 可以分布在云和数据中心吗
- 将每个函数视为独立的服务，可以在不影响应用程序其余部分的情况下对其进行更改、更新或删除
微服务体系结构允许您将应用程序分割成不同的独立服务，每个服务由软件开发组织中的单个组管理。它们支持对构建高度扩展的应用程序至关重要的职责分离，允许在单个服务上独立完成工作，而不会影响其他小组中处理同一整个应用程序的其他开发人员的工作。
简而言之，您的申请可以随着贵公司的成长及其需求增长。您的应用程序看起来更像：
这个图显示了构造为一系列微服务的应用程序。可以看到，每个微服务都有一个明确的团队所有者，每个团队都有一组明确的、不重叠的职责。然而，在实践中，一些服务可能来自第三方，通过api连接，对应用程序所有者可能不是完全可见的。
微服务的简史
马丁有没有记录“微服务”这个术语首先在2011年的软件架构师的研讨会上使用，当参与者发现他们在并行地单独探索软件架构中的类似概念。该集团确认了MicroServices的描述，如描述了次年期间的新范式。
詹姆斯刘易斯在2012年在克拉科夫举行了第33度的演讲，题为“Microservices-Java, Unix方式这将微服务概括为一种通过分割、征服和使用来更快地构建软件的方式康威的法律构建团队。
对于所有美德来说，微服务并不是特别是新鲜或创新的。它的根部回到了三十年Unix世界。很多人，包括这位作者，都说这不过是一个新的转变面向服务的架构（SOA）几十年前，这是所有愤怒的设计原则。（SOA由于赢得了糟糕的声誉太多失败和昂贵的实现.）
福勒指出了许多主要特征这使得microService唯一的，也许是最重要的是保持服务独立，因此可以在不影响整个应用程序的情况下单独更换。他还确定了各种业务职能组织服务，并使用“智能端点和愚蠢管道”的各个要求，所有这些都是“SOA所做的”方面，如2016年的行业专家格雷格年轻人所述介绍当Microservices会议在伦敦。
从那时起，使用微野跑加速了。实际上，根据福勒的说法，微服架构很快“成为构建企业应用程序的默认风格。”
虽然传统智慧持有，MicroServices项目最适合实施全新的分布式软件项目，最近红帽调查显示，大多数使用微服务的企业都成功地部署了它们来重新构建遗留应用程序。超过三分之二(69%)的受访者表示，他们将微服务用于新应用和对现有应用进行现代化改造。
并且益处迅速累积：根据红帽调查在美国，三分之一的组织在首次部署微服务的两到六个月内就取得了优势。
微服务和容器
说到微服务，就不能不提C物箱，这个概念在21世纪初首次出现FreeBSD项目。许多开发人员认为容器是自然的适合微服务。
组成应用程序的服务可以放置在拥有该服务或应用程序所需的最小库和可执行文件的容器中，使每个容器成为一个自包含的包。Docker.提供一种简单的方法来创建，共享和测试容器图像，并在致力于使用容器开发软件的业务中变得非常流行。
虽然容器内的应用程序独立于其他容器中的那些应用程序，但它仍然是从内核或其他编排工具指令的回答。这种编排工具对于管理大量集装箱来说是必不可少的。虽然Docker有自己的编排功能，许多开发、运维和DevOps专业人士更喜欢Kubernetes。（最初由谷歌设计，Kubernetes是一个协调多个容器操作的开源平台。)
当然，不使用容器也可以构建微服务。但是，当实际运行由许多不同微服务组成的应用程序时，您将需要一种管理所有应用程序的方法。容器和容器编排非常适合该任务。
微猎狼如何启用Devops
微服务方法也很好地配合了DevOps，它通过打破软件开发和IT运营团队之间的障碍，加速了软件从开发到生产的过程。在DevOps环境中，开发人员和运维工程师以一种迭代的方式无缝协作，以更快地生产出更高质量的软件。
哲学上，这与微服务架构很好，这有助于您在非常短的生产计划中对应用程序进行快速更改。通过同时利用微服务和Devops，软件组织可以实现不久前被认为是不可能的事情。例如，Amazon能够发布新的代码每11.7秒，而netflix部署新代码每天数千次。
微服务的10个主要好处
根据莱斯最近的调查，使用MicroServices的组织将新的软件速度快五倍，而不是那些没有。使用MicroServices的大多数公司对他们计划在未来六个月继续使用它们的结果非常满意。71％的计划计划增加他们在未来12个月内使用微服务
组织从部署微服务实现的十大福利包括：
- 提高可伸缩性。由于微服务允许您独立地向上或向下扩展服务，因此扩展的便利性和成本都大大低于单片系统。添加新功能通常意味着添加离散的新微服务，而不是重做整个应用程序，这将提高开发速度和应用程序稳定性。
- 更好的故障隔离。如果一个微服务出现故障，其他所有微服务可能会继续工作。这是微服务架构设计的关键部分。
- 优化扩展决策。通过微服务架构，可以在更粒度的水平下进行缩放决策，允许更有效的系统优化和组织。
- 局部复杂性。MicroService架构让开发人员考虑作为黑匣子的服务。服务的业主需要了解仅在其服务中的复杂性。其他服务所有者只需要知道服务提供的功能，而无需担心它在内部运行方式。这种知识和复杂性的统计化使得更容易创建和管理大型应用程序。
- 增加业务敏捷性。微服务相对较小且简单，微服务的失败只会影响该服务，而不会影响整个应用程序，因此企业可以尝试新的流程、算法和业务逻辑。微服务让你可以自由地尝试和“快速失败”。
- 增加开发人员生产力。新开发人员可以快速上手，因为理解一个小的、独立的功能比理解整个独立的应用程序更容易。
- 简化调试和维护。出于相同的原因，建立单个微服务比编码单片架构更容易，在调试代码和执行维护时，开发人员可以更加富有成效。
- 更好地使开发人员与业务用户保持一致。由于微服务架构是围绕业务功能组织的，因此开发人员可以更容易地理解用户的观点，并创建与业务更好结合的微服务。
- 未来的应用。当创新发生和新的或更新的技术中断软件开发过程时，微服务体系结构使得通过替换或升级影响的各个服务而更轻松地响应，而不会影响整个应用程序。
- 较小，更敏捷的开发团队。在现代软件组织中，团队通常由他们工作的微服务组织。这些团队涉及更少的人，他们更专注于手头的任务。杰夫贝斯的着名“两个披萨规则"--认领一个不能用两种比萨饼喂养的软件团队非常大，非常适合于微服务哲学。
微服务的潜在缺陷
然而，没有什么是免费的，微服务体系结构也要承担自己的成本。
- 微服务体系结构可能很复杂。虽然单个微服务可能更容易理解和管理，但作为一个整体，应用程序最终可能会有更多可移动的部分。通常会涉及更多的组件，并且这些组件有更多的相互连接。这些相互依赖增加了应用程序的总体复杂性，这可能会产生问题。
- 微服务方法需要仔细规划。因为应用程序中的所有微服务都必须协同工作，所以开发人员和软件架构师必须仔细计划如何分解所有功能和依赖关系。在从零开始启动应用程序或修改遗留的单片应用程序时，你也可能会遇到数据挑战。除了仔细规划单个微服务，可能还需要多次迭代，直到你做对为止。
- 适当的微服务规模是至关重要的，而且很难计算。如果您使您的微服务太大，您最终可以满足巨石的所有缺点。如果使它们太小，则会将复杂性从个人服务中移动到依赖性映射，这使得应用程序更加难以在比例中理解和管理。更糟糕的是，处理复杂的依赖性通常需要更有经验和更高的有偿开发者和建筑师。
- 您可能对第三方微服务很少控制。许多微服务体系结构包括来自第三方的服务，由您无法访问的团队维护。第三方服务可以在任何时候更改它们的api(或依赖项)，而且可能会破坏您的应用程序。如果他们确实修改了api，你需要知道并能够尽快做出回应。
- 下游依赖性很难跟踪。MicroService成功的一个关键是限制相互依赖性，并仔细追踪您无法避免的。应用程序必须能够在个人微服务的失败中存活，但经常发生下游问题，并且可以通过生态系统级联。建立容错于内置微猎狼的应用程序可以比单片系统更复杂。
- 多个微服务可以提供糟糕的演员更多机会。随着微服务的流行度，它们可能会增加您的应用程序对黑客和网络犯罪分子的脆弱性。因为微服务架构允许您在构建应用程序时使用多个操作系统和语言，因此可能有可能为恶意入侵具有更多“软目标”。此外，您可能无法了解您的应用程序使用的第三方服务的漏洞或行为。
微服务，有效使用时，还清
如果使用有效，微服务体系结构允许您随着应用程序开发人员数量的增加而扩展应用程序。关键是在构建应用程序时不要在宏级别上创建一个复杂的、难以处理的庞然大物。这意味着每次有新服务添加到您的系统或微服务之间建立新连接时，都要保持跟踪。
它也意味着检查复杂性增加并确保其有保证并良好理解。定期检查整个应用系统对于保持相互连接的微服务有效和可靠地工作至关重要。
尽管微服务不是万灵药，但对于数量不断增加的现代软件组织来说，它的好处显然是值得的。通过改变软件开发团队的结构，组织可以创建以特定业务服务为中心的团队，并赋予他们责任和权力，让他们按照自己认为最好的方式行事。这种方法可以让团队随着业务的发展而快速移动，以响应市场需求，而不干扰中心业务活动。单是这一点就值得付出入场费。
监控解决方案，如亚博直播平台New Relic可用于帮助跟踪微猎狼服务之间的互连依赖性。新遗物APM，以及诸如亚博最新版直播New Relic的人工合成物和新的遗物警报，可以监控这些连接的性能，操作特性和SLA，并在检测到问题时提醒您。
