后端技术的发展速度与面向客户的技术一样快。随着用户需求的变化和移动环境的发展，需要升级使这些系统保持运行状态的技术。我们通过PaaS，IaaS和SaaS彻底改变了移动开发领域，现在正致力于 微服务架构 创建可以与更广泛的移动环境连接的应用程序。
最近，“微服务”一词被广泛使用。在过去的几年中，此学期的兴趣明显增加，而且这种趋势似乎并不会很快放缓。很明显，微服务架构处于对服务的最高期望的高峰。 Gartner炒作周期模型.
让我们发现从含义到用途的所有事物。
什么是微服务？
微服务或微服务架构区分了一种架构样式，该架构样式鼓励通过可独立开发，部署，扩展和修订的狭窄接口来开发较小的服务。
微服务是经典单片架构的一种现代替代方法，过去通常涉及到较重的工具和更多的协调工作，最终增加了开发人员的负担。
作为微服务的一部分构建的单功能模块具有明确定义的接口和操作。随着企业寻求更大的敏捷性并转向DevOps和持续测试框架，微服务已变得越来越流行。
微服务是创建可扩展，可测试的软件解决方案的答案，该解决方案可以在短时间内连续交付，这与采用整体架构构建的应用程序需要数月/数年才能完成。
微服务架构与单片架构有何不同
微服务为在敏捷环境中工作的团队带来了很多好处。 网飞, 易趣，Twitter，PayPal和 亚马逊 有些公司已经从单一架构转向微服务。
与微服务相反，整体应用程序是作为一个坚固的单元构建的，这使得对软件的更改变得很烦人。在整体软件中，在软件的一小部分中进行很小的变动或小的更改可能需要您启动该软件的全新版本。
在单片应用程序中，缩放特定功能也是一项艰巨的工作，因为您需要缩放软件的所有部分。
微服务通过允许开发人员创建尽可能模块化的应用程序来解决这些问题。简而言之，使用微服务开发的应用程序可以视为一组服务，而不是固定的服务网格。
让我们进一步探讨基于微服务的应用程序与整体应用程序之间的区别。
微服务的特征
微服务架构有一些明显的特征。我们来看一下。
多种成分
用微服务构建的软件解决方案可以分解为组件。组件化是至关重要的，并且是从单片架构转换为基于微服务的架构的第一步。服务被分解为组件，因此可以对每个服务进行调整，开发和部署。
这种最小依赖状态是微服务的主要优势，因为它允许开发人员更改和重新部署应用程序的特定部分，而不是整个代码。但是，微服务的这一特性带来了成本。远程调用的成本，远程API的成本以及更高的复杂性，因为职责分布在各个组件之间。
逻辑功能边界
这个特性对我们来说很容易说，但是对开发人员来说很难实现。大多数团队在首次将软件从单片服务迁移到微服务时都会遇到此问题。
微服务具有适当范围的功能边界，可以防止开发人员在需要任何微小更改时陷入混乱。与整体应用程序一样，当团队必须对代码的一部分进行细微调整时，他们通常必须与其他团队同步以检查依赖关系，并查看其更改如何影响应用程序的其他部分。
但是，在微服务中，您应该始终知道向每个服务填充了多少东西，因为这确定了可以在应用程序中引入的模块化级别的界限。
轻松路由
微服务的行为很像经典的UNIX系统，在该系统中，服务接收请求，处理请求并相应地输出响应，这与诸如企业服务总线之类的系统形成鲜明对比，在企业服务总线中，系统是为消息路由而安装的。
去中心化
微服务通常涉及各种各样的平台和技术。因此，它们提供了集中式系统，而不是最佳解决方案。微服务的开发人员喜欢分散式系统，因为他们不断努力开发针对常见问题的解决方案，这些问题可以被其他团队重用。
微服务的特征还在于分散的数据库管理系统，其中每个服务分别管理自己的数据库。
防故障
微服务在发生故障时不会破坏周围的一切。采用微服务架构设计的应用能够管理故障。在多个唯一服务相互交互的情况下，其中一种可能会失败。
发生这种情况时，该服务无需费吹灰之力，就可以继续其相邻的服务，同时还可以避免妨碍。对微服务的持续监视可以帮助检测这种故障。
但是，这种监视需求增加了整个应用程序结构的复杂性。
进化的
当您无法完全预期可以访问您的应用程序的设备和平台的种类时，微服务架构可以为该问题提供解决方案。
现在过于僵化而无法继续运行的单片应用程序可以正常过渡到微服务应用程序，并使用API与基础经典结构进行交互。
为什么微服务很重要
为了更好地理解微服务为何对应用程序开发的未来具有革命性和必不可少的作用，让我们了解微服务的先驱，即整体架构。
集中化是整体架构的核心，因此，更新和修订是一项繁重的任务。
以下是整体架构所存在的一些挑战：
- 缺乏灵活性 –不能使用多种技术来构建整体应用程序。
- 不可靠 –当系统的一部分发生故障时，整个单片应用程序将停止。
- 不可扩展性 –用单片式架构构建的应用程序无法轻松扩展，因为需要重建整个系统。
- 相互依存 –开发人员缺乏独立性，因为大多数模块都在等待其他模块的开发，因此它们可以完成。
- 发展步伐 –整体应用程序需要花费大量时间才能进入市场，因为必须考虑到依赖性，一个接一个地开发模块。
微服务通过允许开发人员在跨职能团队中并行工作并按时交付产品来解决几乎所有这些问题。
这是微服务架构的一些显着优势：
- 独立开发和部署
- 误隔离
- 混合技术堆栈
- 粒度（按需）缩放
微服务优先方法
如果您开始开发应用程序，则可能需要保持模块化。对于模块化带来的所有好处，您可能试图在应用程序中划分职责范围。
企业和公司的目标是基于微服务的应用程序在其解决方案中引入可扩展性和易维护性。但是，从理论上讲，模块化甚至可以引入单片架构。但是，问题出在我们开发具有整体架构与微服务架构的应用程序的方式上。在前一种情况下，开发人员通常会急于开发和部署解决方案，并尽快将其发布。
发生这种情况时，开发的边界就会模糊，因此，应用程序将失去其模块化。从长远来看，这些重叠的服务使扩展和优化应用程序变得困难。本质上，即使是最简单的单片应用程序也具有集中式数据库。分散化是微服务应用程序的核心，因此与微服务形成了鲜明的对比。
因此，当模块化和分散化对于应用程序至关重要时，应选择微服务优先方法，该应用程序将具有高流量，长期利益比短期目标更可取，正确的资源集可用于项目，以及团队致力于使用最新技术的时间。
何时使用微服务及其已知用途
实施微服务时经常被忽略的一个挑战是确定采用微服务架构是否有意义。当团队开发其应用程序的第一个版本时，他们通常不会遇到微服务解决的问题。但是，随着项目的进行，他们往往会面临相同的问题。
微服务的分布式体系结构减慢了开发过程，通常会增加对人力资源的需求。对于人才储备有限的初创企业和急于启动其项目的企业而言，这可能是一个障碍。
因此，企业必须考虑微服务是否是对其应用程序开发的最佳选择。诸如Amazon，eBay和Netflix之类的大多数大型网站已将其体系结构从单片服务演变为微服务。流行的视频流服务Netflix具有面向服务的体系结构。 Netflix每天处理超过10亿次呼叫，每个呼叫平均向后端服务扇出6个呼叫。另一方面，亚马逊最初具有两层架构。但是，在进行扩展时，他们迁移到了具有数百个后端服务的面向服务的体系结构。
如今，许多其他网站都将这些服务称为“服务”，其中包括那些实现了Amazon Web Service API的网站。 Amazon.com网站调用约150种服务来获取构成其网页的数据。 eBay是网站从单体架构演变为微服务的另一个示例。 eBay根据功能进行了分层，因此每个应用程序层都实现了用于买卖的业务逻辑。
还有许多其他公司使用微服务。探索更多 这里.
最后的话
微服务架构不是一个新概念。他们以前以面向服务的体系结构，Web服务等形式存在。但是，最新工具和技术的可用性，无法与其他任何体系结构一起获得预期结果的挫败感，IaaS和DevOps的广泛采用以及许多其他原因相互叠加，导致它们的数量激增人气。
顺带一提，我们将看到它发展到一个水平，在该水平上，软件工程师将仅使用整体来进行原型制作。在部署方面，为什么不选择模块化程度更高，高性能以及易于扩展的应用程序/系统呢？
在接下来的几篇文章中，我们将探讨公司如何实施微服务，微服务实施路径面临哪些挑战，以及如何在业务场景中成功地制定战略和实施微服务。微服务将继续存在，看到许多其他巨头在采用整体式架构之后又转向微服务也就不足为奇了。
继续阅读
寻找免费咨询吗？让我们连接。我们很乐意听取您的意见。
联系我们
