微服务架构体系——它适合您的软件开发吗?

“Microservice architecture provides a range of technical benefits that contribute to the development velocity and product quality in software projects, while also contributing to the overall business agility”– Mark Emeis, Senior director of software technologies, CA Technologies

自从“微服务”这个术语出现以来，它在软件开发方面已经取得了进展。微服务，又名微服务体系结构，是面向服务体系结构(SOA)的变体，用于开发大型应用程序，其中服务根据业务领域的具体情况被划分为多个块。它支持复杂应用程序的持续交付/部署，使应用程序更易于理解、开发和测试，并且对体系结构的侵蚀更有弹性。微服务体系结构提供了一种以新颖的方式编织现有系统的新方法，以便快速交付软件解决方案。它是软件行业中最热门的话题之一，因为它能够提供模块化、可伸缩性和可用性;许多企业软件开发公司都热衷于采用它。

Microservices究竟是什么?

微服务能改善组织的文化、技能和需求吗?为了深入理解微服务，让我们首先了解相反方法的要点:单体架构。

关于单体软件的

维基百科说，“一个单一的应用程序描述了一个单层的软件应用程序，其中用户界面和数据访问代码从一个平台合并成一个程序。”

单体架构软件使用三层结构:

• Presentation Layer – 应用程序的最顶层，并描述用户界面。主要功能是将任务和结果转换为用户能够理解的内容。用户界面代码是用HTML、JavaScript和CSS等客户端技术编写的。
• Business Layer – 该层做出逻辑决策并执行计算。它处理两层之间的数据，并使用Spring等技术。
• Data Access Layer –在这里，信息从数据库中存储和检索。信息被传递到业务层，然后最终传递给用户。它使用像Hibernate这样的ORM工具来处理信息。

web应用程序客户机发送请求，层执行业务逻辑，数据库存储应用程序特定的数据，UI向用户显示特定的数据。但是，由于它们共享相同的代码库，可能会出现一些问题。

这种类型的体系结构在一段时间内运行良好，但是由于对持续交付的需求不断增加，这种模型存在多个问题。

单体架构的缺点

• Operational Overhead: 不同的涉众使用不同的单体应用程序层;因此，团队将局限于特定的领域专家。在表示层工作的团队专门从事UI技术，但对数据访问层的知识最少。因此，如果要添加新特性，就需要不同的团队来协调并交付特定的特性。这导致了从构思到投放市场的更长的时间跨度，并最终影响业务ROI。
• Software stack autonomy: 它限制了技术选择，迫使整个层使用单一框架。例如，如果表示层是在HTML框架中编写的，那么整个层将在同一个框架中实现。这避免了实现最新的技术，从而导致应用程序代码在短时间内变得过时。
• Implicit Interface: 由于这代码是在单个文件中发布的，因此应用程序中的一个小更改需要重新构建整个应用程序。因此，不断进行的应用程序被放下，导致需要重新部署新版本。这种特性导致更新更少，并且不能以应有的速度发展。
• Scalability: 单体应用程序具有一维可伸缩性;因此无法缩放各个组件。因此，整个应用程序需要缩放，即使大多数应用程序可能不需要缩放。

没有良好的体系结构开发软件会给组织带来很大的成本。例如:如果软件开发公司采用非模块化的方法开发软件，其中UI功能和业务功能混合在相同的源文件中，那么公司可能需要投入大量资金来支持其在最新的智能手机原生应用程序中的应用程序。这严重影响了软件的可维护性，增加了上市时间，最终影响了公司的销售。

单片架构一直是传统的方法，但是由于伸缩性的限制、维护大型代码库的困难、高风险的升级和大量的前期设置成本，迫使企业或软件开发公司探索不同的方法。单片应用程序是一个很难解决的难题，并且随着时间的推移难以理解和扩展。

因此，为了避免这些问题，微服务体系结构可以成为救世主!为解决上述复杂性提供了360度扭转;帮助软件开发公司在竞争对手中脱颖而出。

微服务体系架构简介

微服务体系结构是一种软件开发技术，它将应用程序构造为松散耦合服务的集合。每个服务都是自包含的，应该实现单个业务功能。微服务体系结构旨在克服大型应用程序的挑战、故障和故障。微服务提供了向系统添加弹性的机会，以便组件能够优雅地处理尖峰和错误。这样，每个涉众都可以只关注整个应用程序的一个特定元素，使用自己的编程风格，而不关心其他组件。微服务中的通信可以毫不费力地进行，因为它们是无状态的，并且在定义良好的接口中(请求和响应是独立的)。

如果应用/软件是使用微服务方法开发的，它将有助于采用DevOps方法，并将消除部署效率低下，从而缩短上市时间。由于微服务与设备和平台无关，因此它能够开发应用程序，为大多数平台(包括web、移动设备、物联网、平板电脑、可穿戴设备等)提供增强的用户体验。

例如，沃尔玛加拿大公司在2012年之前就使用了单片架构!该公司在处理600万次/分钟的页面浏览量时遇到了问题，这消耗了更多的时间，导致销售减少。由于这些问题，他们将软件架构重构为微服务，并在一夜之间发现了即时结果和高转化率。停机时间最小化，公司能够使用更便宜的x86服务器，而不是昂贵的硬件，从而节省了20%-50%的成本。

Microservices 和 SOA

它是SOA的自然演进，各种技术堆栈将技术多样性引入开发团队。SOA和微服务都允许将复杂的工作负载分解为更小、更易于管理和独立的部分。

然而，两者之间有一些基本的区别。

Microservices vs SOA

关注分离和有界上下文系统的改变创造了新的服务关注持续交付和DevOps使用轻量级协议，如HTTP、REST等。各个微服务之间提供了独立的数据存储

Microservices哲学

微服务的哲学类似于Unix哲学，“只做一件事，做好它”。其特点如下:

执行单个功能的组件化

根据业务能力进行组织

关注产品，而不是过程

分散的治理和数据管理

服务是弹性的、弹性的、可组合的、最小的和完整的

为什么软件开发公司应该投资于微服务架构?

Improves Fault Isolation

在微服务体系结构中，开发人员确切地知道在何处查找要解决的问题。如果单个模块受到影响，它可以很容易地拆卸或解决，而不影响应用程序的其他部分;提高应用程序的可用性。这在单片应用中是完全矛盾的;单个组件的故障可能导致整个应用程序崩溃。例如，移动游戏应用程序(构建在单块架构上)有不同的组件，比如支付、登录、玩家、历史等等。如果一个特定的组件开始消耗更多的内存空间，整个应用程序将受到影响，这将导致糟糕的用户体验。

Easy to Modify the Technology Stack

通过使用微服务，软件开发公司可以在特定组件上尝试新的堆栈或最新技术，以提高可用性，并在应用程序级别获得更大的好处。由于不存在依赖问题，如果软件开发人员没有提供一致的用户体验，他们可以避免使用特定的技术栈。这样持续的现代化，你的系统不会轻易过时。

Provides scalability微服务对有性能问题的部件进行扩展，并使用最符合服务需求的硬件。由于每个服务都是单独的组件，因此可以使用更多的容器部署可伸缩性，从而实现更有效的容量规划、更少的许可成本和适当的硬件。关键服务的组件可以部署在多个服务器上，以提高可用性和性能，而不会影响其他服务的性能。这种可伸缩性可以带来更好的客户体验并节省成本。

Aligned With the Organization

如果一个组织正在使用微服务，那么可以定义团队规模来匹配所需的任务。此外，团队可以被分成更小的小组，并且可以专注于应用程序的单个组件。由于最终目标是客户满意度和良好的用户体验，所以团队不分为UI团队、数据库团队等。例如，如果在UAE工作的团队要处理3个服务，而在California工作的团队要处理5个服务，那么在California和UAE工作的每个团队都可以独立发布和部署不同的功能。这些跨职能团队致力于实现单一功能，打破团队之间的隔阂，促进更好的协作。

Improved Productivity and Speed

有了微服务，生产率和速度可以很容易地解决。不同的团队可以同时处理不同的组件，而不必等待一个团队完成任务。这就加快了质量保证的速度，因为每个微服务都可以单独测试。其他涉众可以致力于增强已经开发的组件，而其他程序员则致力于其他组件。这提高了速度，并导致更快的产品发布。

需要考虑的障碍

仅仅因为一切看起来都很华丽，并不意味着它对软件行业来说是完美的;它确实有潜在的痛苦，这也需要解决:

由于微服务侧重于分布式系统和独立服务，每个请求都需要在模块之间小心处理。其中一个服务可能没有响应，这迫使开发人员编写额外的代码以避免中断。

基于微服务的应用程序的测试可能是一项痛苦的任务，因为在开始测试之前需要确认每个依赖的服务。随着服务数量的增加，复杂性不再停留在后台!在所有服务上保留标签变得不切实际，因为可能会出现数据库错误、网络延迟、缓存问题等。因此，弹性测试和错误注入成为了必须。

每个服务都依赖于它自己的API和平台，跟踪每一件事都是一项痛苦的工作。领导者需要监视多个实体并管理整个基础设施，因为如果任何服务出现故障，跟踪问题就变得很乏味。因此，健壮的监视是必要的。

随着持续的交付和快速的发展，员工必须跟上敏捷性和速度要求利用微服务的好处。如果他们花很长一段时间提供服务器，公司可能会陷入严重的麻烦。

微服务和整体架构之间区别

整个应用程序中的每个组件都必须很小，并且必须交付最终目标不同的技术可以用于不同的微服务

微服务架构的未来

您可能已经清楚地了解了微服务体系结构及其改变软件行业的潜力!随着数字技术和多设备支持的日益普及;软件开发正在深入到复杂的过程中。但是软件行业有幸拥有微服务体系结构，它可以作为解决软件开发公司复杂性的完美解决方案。如果公司想采用它，它肯定会在技术和操作上影响企业文化。

大公司已经在使用中

今天，随着微服务的兴起，大多数公司都在推倒单体架构，采用现代架构来在激烈的竞争中发挥作用。其中包括Netflix、eBay、亚马逊(Amazon)、Twitter、贝宝(PayPal)、沃尔玛(Walmart)等等……

Netflix

NetFlix是最早在SOA体系结构中使用微服务的公司之一。在公司快速增长的时候，无法建立数据中心来提供可伸缩性。开发中的小问题需要软件开发人员一次又一次地寻找问题。但是，当他们用微服务重构现有的架构时，他们每天能够通过800种不同设备的api处理10亿个调用。如今，Netflix正在使用500+微服务和30+工程团队。

优步

优步开始了它的微服务之旅，在一个城市建立的单一的单体架构。由于它只在一个城市运行，一个代码库选项似乎是干净的选项，可以解决所有的业务问题。但是，当它迅速扩展到其他城市时，组件变得紧密耦合，封装是另一个问题，而持续集成则是一个负担。因此，为了解决所有这些复杂性，工程团队重构了现有的应用程序并使用了微服务。

1.所有乘客和司机通过API网关连接

2.部署单独的单元来执行单独的功能

3.所有功能都可以单独缩放

因此，从单体架构到微服务架构的转变让优步受益匪浅。

Amazon

亚马逊是大型电子商务商店之一，它遵循单体的应用程序，使开发人员彼此分离，并将团队从最终目标中分离出来。该公司必须解决协调过程之间的冲突，将它们合并为一个单独的版本，并生成所有版本的主版本。需要重新运行全新的代码库、测试用例，以确保没有仓促的工作。这些小故障使得公司使用微服务架构!这个软件解决方案通过自己的web服务api与世界进行通信。因此，它非常成功。

做出选择

无论你选择是整体服务还是微服务，两者都有其优点和缺点。最后，选择软件架构取决于您的项目需求、项目的大小等等。如果您希望构建小型软件，那么单体架构是一种选择，如果您喜欢开发复杂的软件，那么微服务体系结构无疑是一个很好的选择。