“微服务架构提供了一系列技术优势，有助于提高软件项目的开发速度和产品质量，同时也有助于提高整体业务灵活性” - MARK EMEIS，软件技术高级总监，CA技术
自从该术语成立以来，微服务一直在软件开发中获得成功。微服务（又称微服务架构）是面向服务的体系结构（SOA）的变体，用于开发大型应用程序，其中服务按照业务域分为多个块。它提供了复杂应用程序的持续交付/部署，使应用程序更易于理解，开发，测试，并且对架构侵蚀更具弹性。微服务架构提供了一种以新颖方式编织现有系统的新方法，以便快速提供软件解决方案。由于其提供模块化，可扩展性，可用性的能力，成为软件行业最热门的话题之一;许多企业软件开发公司都热衷于采用它。
但是，微服务究竟是什么？它能改善组织的文化，技能和需求吗？
为了深入理解微服务，让我们首先理解相反方法单片架构的要点。
关于单体软件的一切
维基百科说：“单片应用程序描述了一个单层软件应用程序，其中用户界面和数据访问代码从单一平台组合成一个程序。”
单片软件使用三层架构，即
- 表示层 - 它是应用程序的最顶层，描述了用户界面。主要功能是将任务和结果转换为用户可以理解的内容。用户界面代码使用HTML，JavaScript和CSS等客户端技术编写。
- 业务层 - 该层做出逻辑决策并执行计算。它处理两层之间的数据，并使用像Spring这样的技术。
- 数据访问层 - 这里存储信息并从数据库中检索信息。信息将传递到业务层，最终传递给用户。它使用像Hibernate这样的ORM工具来处理信息。
这里，Web应用程序客户端发送请求;层执行业务逻辑，数据库存储应用程序特定数据，UI将特定数据显示给用户。但是，由于它们共享相同的代码库，因此可能会出现一些问题。
这种类型的架构在一段时间内运行良好，但由于对持续交付的需求不断增加，此模型存在多个问题。
单片架构的缺点
- 运维开销：不同的利益相关者使用不同的单一应用层;因此团队将被限制在特定领域的专业知识。在表示层工作的团队专注于UI技术，但对数据访问层的了解最少。因此，如果要添加新功能，则需要不同的团队来协调和传递特定功能。这导致从构思到上市时间的更长时间跨度，并最终影响业务ROI。
- 软件堆栈自治：它限制了技术选择并迫使整个层使用单一框架。例如，如果表示层是在HTML框架中编写的，则整个层将在同一框架内实现。这避免了实施最新技术，导致应用程序代码在短时间内过时。
- 隐式接口：由于此代码在单个文件中发布，因此应用程序中的微小更改会要求重建整个应用程序。因此，正在进行的应用程序被放下并导致需要重新部署新版本。这种性质导致更新更少，并且无法尽可能快地发展。
- 可扩展性：单片应用程序具有一维可扩展性;因此无法扩展单个组件。因此，即使大多数应用程序可能不需要扩展，也需要扩展整个应用程序。
开发没有良好架构的软件会给组织带来很大的成本。例如：如果软件开发公司通过遵循非模块化方法开发软件，其中UI功能和业务功能混合在相同的源文件中，公司可能需要投入大量资金来支持他们在最新智能手机本机中的应用程序应用。这严重影响了软件的可维护性并延长了产品上市时间，最终影响了公司的销售。
单片体系结构一直是传统方法，但是扩展的限制，维护大型代码库的困难，高风险升级以及大量的前期设置成本迫使企业或软件开发公司探索不同的方法。单片应用程序是一个难以破解的难题，难以理解并随着时间的推移而扩展。
因此，为了避免这些问题，微服务架构可以成为一个救星！它提供360度扭曲以解决上述复杂问题;帮助软件开发公司在竞争对手中脱颖而出。
微服务架构简介
微服务是一种软件开发技术，它将应用程序构建为松散耦合服务的集合。每项服务都是独立的，应该实现单一的业务能力。微服务架构旨在克服较大应用程序的挑战，故障和故障。微服务提供了为系统增加弹性的机会，以便组件可以优雅地处理峰值和错误。有了这个，每个利益相关者都可以专注于整个应用程序的一个特定元素，具有自己的编程风格，而不用担心其他组件。微服务中的通信可以毫不费力地执行，因为它们是无状态的并且在明确定义的接口中（请求和响应是独立的）。
如果使用微服务方法开发应用程序/软件，将有助于采用DevOps方法，并将消除部署效率低下，从而缩短产品上市时间。由于微服务与设备和平台无关，因此可以开发应用程序，在大多数平台上提供增强的用户体验，包括Web，移动，物联网，平板电脑，可穿戴设备等等。
例如：沃尔玛加拿大在2012年之前使用了单片架构！该公司在处理600万页面浏览量/分钟时遇到了麻烦，这耗费了更多时间并导致销售额减少。由于这些问题，他们将自己的软件架构重构为微服务，并在一夜之间找到了即时结果和高转换率。停机时间最小化，公司能够使用更便宜的x86服务器而不是昂贵的硬件商品，从而节省了20％-50％的成本。
微服务和SOA
这是SOA的自然演变，其中各种技术堆栈将技术多样性带入开发团队。 SOA和微服务都允许将复杂的工作负载分解为更小，更易于管理和独立的部分。
但是，它们之间存在一些基本差异。
微服务与SOA
微服务哲学
微服务的哲学类似于Unix哲学，即“做一件事，做得好”。特征描述如下......
- 用于执行单一功能的组件化
- 按业务能力组织
- 专注于不加工的产品
- 分散治理和数据管理
- 服务具有弹性，弹性，可组合性，最小化和完整性
软件开发公司为什么要投资微服务架构？
- 改善了故障隔离
在微服务架构中，开发人员确切地知道在哪里寻找要解决的问题。如果单个模块受到影响，则可以轻松拆卸或解决，而不会影响应用程序的其他部分;提高应用程序的可用性。这在整体应用中完全矛盾;单个组件的故障可以拉低整个应用程序。例如，移动游戏应用程序（基于单片架构），具有不同的组件，如支付，登录，播放器，历史记录等。如果特定组件开始占用更多内存空间，整个应用程序将受到影响，这将导致糟糕的用户体验。
- 易于修改技术堆栈
通过微服务，软件开发公司可以在特定组件上尝试新的堆栈或最新技术，以提高可用性并在应用程序级别获得更大的好处。由于没有依赖性问题，软件开发人员可以避免使用特定的技术堆栈，如果他们不提供一致的用户体验。通过这种持续的现代化，您的系统不会变得容易过时。
- 提供可扩展性
微服务可扩展存在性能问题的部件，并使用最符合服务要求的硬件。由于每个服务都是独立的组件，因此可以使用更多容器部署扩展，从而实现更有效的容量规划，更少的许可成本和适当的硬件。关键服务的组件可以部署在多个服务器上，以提高可用性和性能，而不会影响其他服务的性能。这种可扩展性可带来更好的客户体验并增加成本节约。
- 与该组织保持一致
如果组织使用微服务，则可以定义团队规模以匹配所需任务。此外，团队可以分解为更小的组，并可以专注于应用程序的单个组件。由于最终目标是客户满意度和良好的用户体验，团队不分为UI团队，数据库团队等。例如，如果在阿联酋工作的团队正在处理三项服务，而在加利福尼亚工作的团队正在处理五项服务，那么在加利福尼亚和阿联酋工作的每个团队都可以独立发布和部署不同的功能。这些跨职能团队致力于实现单一功能，打破团队之间的孤岛，促进更好的协作。
- 提高生产力和速度
通过微服务，可以轻松解决生产率和速度问题。不同的团队同时处理不同的组件，而无需等待一个团队完成任务。这样可以加快质量保证，因为每个微服务都可以单独测试。其他利益相关者可以致力于增强已经开发的组件，而其他程序员则在开发其他程序员。这样可以提高速度并加快产品的发布速度。
需要考虑的障碍......
仅仅因为，一切看起来都很华丽，并不意味着它对软件行业来说是完美的;它确实有潜在的痛苦，也需要解决： -
- 由于微服务侧重于分布式系统和独立服务，因此需要在模块之间仔细处理每个请求。可能会发生其中一个服务没有响应，迫使开发人员编写额外的代码以避免中断。
- 基于微服务的应用程序的测试可能是一项痛苦的任务，因为在开始测试之前需要确认每个依赖服务。随着服务数量的增加，复杂性不会留在后台！密切关注所有服务变得不切实际，因为可能会出现数据库错误，网络延迟，缓存问题等。因此，弹性测试和故障注入成为必须。
- 每项服务都依赖于自己的API和平台，追踪所有内容都可能是一项痛苦的堆叠工作。领导者需要监控多个实体并管理整个基础架构，因为如果在任何情况下任何服务都失败，追踪问题就变得很繁琐。因此，强有力的监测变得必要。
随着持续交付和快速发展，员工必须提高灵活性和速度，这需要利用微服务带来的好处。如果他们花费很长时间来配置服务器，公司可能会遇到严重问题。
单体架构和微服务架构的区别
微服务架构的未来
您可能已经清楚了解微服务架构及其改变软件行业所具有的潜力！随着数字技术的使用越来越多，设备支持越来越多;软件开发正在深入到复杂的过程中。但软件行业拥有微服务架构，可以作为解决软件开发公司复杂性的完美解决方案。如果公司考虑采用它，它肯定会在技术和操作上影响文化。
Big Giants已经在使用它......
今天，随着微服务的兴起，大多数组织正在拉低整体架构并采用现代架构来利用激烈的竞争。其中一些包括Netflix，eBay，亚马逊，Twitter，PayPal，沃尔玛等等......
让我们看看NetFlix如何解决......
- NetFlix：NetFlix是最早在SOA架构中使用微服务的采用者之一。公司快速发展的时候，无法建立数据中心来提供可扩展性。开发中的一些小问题需要软件开发人员一次又一次地查找问题。但是，当他们使用微服务重构现有架构时，他们每天能够通过800个不同设备的API处理十亿次呼叫。如今，Netflix正在使用500多个微服务和30多个工程团队。
- 优步：优步以单一建筑为单一城市的单一建筑开始了它的旅程。由于它只在一个城市运营，因此一个代码库选项似乎是一个干净的选择并解决了所有业务问题。但是，当它迅速扩展到其他城市时，组件变得紧密耦合，封装是另一个问题，持续集成变成了一种负担。因此，为了解决所有这些复杂问题，工程团队重构了现有的应用程序并使用了微服务。他们介绍了
- 所有乘客和司机都通过的API网关
- 部署单独的单元以执行单独的功能
- 所有功能都可以单独缩放
因此，优步通过从单片架构转向微服务架构而获益匪浅。
- 亚马逊：亚马逊是大型电子商务商店之一，紧随其后的是整体应用程序，它使开发人员彼此分开，并将团队与最终目标区分开来。该公司必须解决协调过程之间的冲突，将它们合并为一个版本并生成所有版本的主版本。需要重新运行全新的基于代码的测试用例，以确保没有任何冲动。这些故障使公司使用微服务架构！该软件解决方案通过自己的Web服务API与全世界进行通信。因此，它非常成功。
做出选择
无论选择哪种软件解决方案，无论是单片还是微服务，都有它们各有优缺点。最后，选择软件架构取决于您的项目要求，项目规模等等。如果您希望构建小型软件，单片机可以作为一种选择，如果您更喜欢开发复杂的软件，那么微服务架构肯定是一个肯定的镜头。
仍然不清楚您的要求或希望为您的下一个大项目重构现有的软件架构？请联系我们，我们的技术顾问会回复您解决您的疑问！
