微服务vs单片机。2021年的终极比较
IP：Bhagya 微服务vs单片机。为什么微服务是冲击软件市场主线的新东西，而单片机的方法却在失去价值？
通过
·
21年8月9日 -微服务区 -分析
喜欢 (1)
评论
保存
Tweet
118次浏览
加入DZone社区，获得完整的会员体验。
微服务与单片机
微服务是冲击软件市场线的新东西。在微服务的新兴趋势中，关于微服务与单片机的争论是不可避免的。微服务架构提供了实实在在的好处，如可扩展性和灵活性，是创建重型应用程序的一种成本效益方式。像Netflix、亚马逊和甲骨文这样的科技巨头一般都在一个或另一个应用程序中实施微服务。相反，单体方法正在失去其价值，因为它给当前的软件交付方法带来了风险。在我们进入微服务与单体的最终比较之前，让我们逐一看一下这两种架构。
1.什么是微服务？
微服务是围绕着复杂的应用而建立的小型可部署的服务。微服务只不过是面向服务的架构（SOA）的一个更新版本。它们使用不同的技术相互沟通，而且它们也有技术不可知的优势。
从技术角度来看，微服务通过多个小服务暴露了它们所封装的应用程序的一个业务/技术能力。不同的微服务通过API端点/HTTP协议进行通信，使其成为一个分布式系统。
上面的图片显示了一个分布式架构，它是由微服务的实施所促成的。该图表明，小型微服务可以部署在一组异质的主机上。这些主机的范围可以从裸机实例到公共云。这种分布式架构增加了整个应用程序的高可靠性、可扩展性和可移植性。
2.什么是单片机？
单片机这个词来自于古代对一块巨大岩石的表述。当我们谈论软件时，单片机只不过是一个具有多个模块的大型代码块。这些模块相互之间是紧密耦合的。应用程序和业务逻辑被封装在一个叫做单片机的可部署的二进制文件中。通常，单体由传统的三层架构组成，即数据库、用户界面和服务器端应用程序。下图概括地表示了单片机的概念。
3.微服务与单体。架构
在深入研究这两个惯例的其他方面之前，让我们先了解一下微服务与单片机的架构。
让我们从单片机开始。单片机是一个统一代码的单一构建。这通常由三部分组成，用户界面、数据库和服务器端应用程序。服务器端应用程序通常处理所有的HTTP请求并执行业务逻辑。在单片机中，服务器端逻辑、用户界面逻辑、批处理作业等都被捆绑在一个EAR（企业存档）、WAR（网络存档）或JAR（Java存档）文件中。图2.1向我们展示了单片机架构的高层表示。
与上述相反，"micro "这个词的意思是小，而微服务表示完成业务逻辑的小服务的集合。这种架构风格的目的是创建小的服务套件，这些服务加起来可以构建一个更大的应用程序。所有的微服务都运行它们的流程来实现这一工作，并拥有轻量级的通信机制，即HTTP资源API。这些微服务是围绕业务逻辑独立构建的，并有完全独立的部署机制。
4.微服务与单体。优点和缺点
在阅读本博客的介绍部分时，你的脑海中一定有一个画面，那就是微服务比单体有优势。这并不仅仅适用于微服务。单片机也有一系列明显的优势，在决定你的应用程序的最佳架构时，应该考虑这些优势。让我们来谈谈微服务与单片机的优点和缺点。
单片机架构的优点
易于开发和部署
单片式应用程序自古以来就存在。众多的工具确实促进了开发和部署策略的简化。开发人员需要执行单一的可部署的代码块，而不是在单独的实体中进行更新。
性能
与微服务相比，更好的性能是单片机应用的一个重要优势。一个基于微服务的应用程序可能需要对其他100个微服务进行100次不同的API调用来加载一个UI屏幕。而在单片机中，一个API调用可以达到同样的目的，因为它有一个集中的代码和内存。
单片式架构的缺点
紧密耦合
单片式应用程序中的服务模块是紧密耦合的。业务逻辑被紧密地纠缠在一起，使得应用程序很难被隔离，因此可扩展性成为一个挑战。
缓慢的构建和发布周期
由于代码库是巨大的，这延迟了应用程序的开发和测试周期的速度。
微服务架构的优点
更好的组织
由于整个代码库被分解成较小的服务，它的组织性相对较好。微服务有一个特定的工作，不依赖于其他组件。
提高敏捷性
有了微服务，团队中的每个人都可以在单个模块上工作。每个人都可以独立构建一个模块和部署一个模块，从而减少团队的操作摩擦，提高软件交付的敏捷性。
上图说明了团队中的每个开发人员都可以自由地工作在独立的模块上。代码库、构建和部署是相互独立的。由于所有的元素都是相互松散耦合的，它提高了整个软件开发生命周期（SDLC）的敏捷性。
5.5.微服务。使用案例
微服务在多个科技巨头中被广泛采用。微服务的实施因个案的不同而不同。但一些在微服务上运行并被日常使用的重要应用包括。
Uber案例研究
像许多初创公司一样，Uber也是从一个单体架构开始的，该架构是为了在单一城市运行出租车聚合服务。随着时间的推移，Uber严格的全球扩张带来了许多关于其可扩展性和持续集成管道的挑战。
上图描述了Uber曾经遵循的旧架构。有一个连接司机和乘客的REST API。在API中使用了三个不同的适配器，用于计费、支付、电子邮件和信息。MySQL数据库被用来存储所有的数据。因此，该应用程序的所有功能都被封装在一个单一的框架中。这个单一的框架在扩大应用规模的时候拥有突出的挑战。
现在，让我们来看看下图，了解Uber为提升其技术发展战略所带来的变化。
引入了一个API网关来连接所有的司机和乘客。API网关通过REST API调用，在内部连接了所有的微服务，如乘客管理、司机管理、行程管理等。
每个微服务都执行一个单一的功能，并有单独的可部署的二进制文件。例如，如果你改变了司机管理微服务中的任何内容，你只需要构建和部署司机管理微服务，而不需要碰其他微服务。
由于所有的微服务都是松散耦合的，它们的相互依赖性大大降低。因此，所有单独的微服务都可以扩展到任何级别。例如，寻找出租车的人数在任何时候都比预订出租车或付款的人数要多。在这种情况下，涉及到行程预订和行程支付的流程和服务都可以向上扩展。
这样一来，世界上最大的出租车聚集公司Uber就通过将其架构从单体迁移到微服务而获益。
6.微服务与单体。部署策略
单片机遵循传统的部署方式，而微服务则让系统架构师在设计部署策略时遇到困难。由于单体具有三层架构，它们总是被部署在Web服务器上，如Apache Tomcat、Oracle Weblogic、IBM Websphere，等等。
让我们来关注一下微服务的部署策略。微服务以高可扩展性而闻名；因此，支持的IT基础设施也应该是可扩展的。下面是一些可供选择的部署策略，以满足你的要求。
一个服务--一台主机
这是一种部署应用程序的传统方法。多个服务可以部署在一个虚拟机上。一个虚拟机被配置并用于部署各种服务。这最终降低了基础设施的成本，因为所有的服务都在一台主机上运行。
一个服务--一个容器
在这种模式下，在支持Docker和Kubernetes的生态系统上运行的应用程序起到了关键作用。服务被打包成图像，并被部署在虚拟主机的容器中。容器是令人难以置信的轻量级，易于构建。容器化实现了服务的完全隔离。微服务的容器化也优化了基础设施成本，因为多个服务被托管在一个虚拟机上。
无服务器部署
用Node.js、Python和Java等编程语言开发的应用程序可以支持无状态和无服务器部署。一个Lambda函数被创建，它运行微服务并处理所有请求。同样，这种策略是最具成本效益的策略之一，因为企业只对云环境中的请求数量进行收费。
7.微服务与单体。运营影响
在考虑任何基础设施时，我们想到的第一个问题是："新技术对运营的影响是什么？"如果你已经决定采用微服务，毫无疑问，你应该考虑一些重大影响。
成本
有几个方面属于 "成本 "的范畴。启动成本、维护成本、开发成本、质量成本、速度和性能成本，以及所有权成本。成本是高管们在做出采用任何软件架构的最终决定时想到的一个重要因素。
可靠性
说到可靠性，微服务在这里也占了上风。单片机只不过是一大块应用程序的二进制文件而已。只要有机会，如果部署失败，整个应用程序就会瘫痪。与单体相比，微服务是非常可靠的。即使在一个服务失败的情况下，应用程序也不会整体瘫痪。有多种服务检测工具，如Hashicorp Consul，它检查每个服务的心跳。在高层次上，在微服务上运行的应用程序的可靠性更高。
可扩展性
单体可以通过多种方式进行扩展。其中之一是使用众多的虚拟机，然后使用负载平衡器路由请求。微服务架构更加细化，因此对每个微服务的扩展也更加细化和灵活。 可扩展性是任何企业应用程序的一个对比因素。因此，市场上有多种技术，可以确保微服务在水平和垂直方向上的可扩展性。市场上一些流行的工具是亚马逊EKS、亚马逊ECS、Docker和Kubernetes。对于精确扩展和更好地利用资源，微服务显然是一个赢家。
如果你想了解更多之前提到的工具，我向你推荐这篇关于亚马逊ECS与EKS的博客，它描述了每一个工具，并帮助你了解何时选择其中一个。
进入市场的时间
由于其庞大的规模和较高的依赖性，单体的构建和部署机制更加复杂和耗时。微服务对资源的敏感度较低，而且是为了扩展而构建的。由于模块之间是相互解耦的，所以更容易构建和部署。这增加了运行在微服务上的应用程序的敏捷性，并大大减少了微服务应用程序进入市场的时间。
8.如何从单片机迁移到微服务？
在你从单片机迁移到微服务之前，有一些具体的应用层面的变化是你应该采用的。我们将在高层次上讨论拥抱微服务的几种方法。
构建优化
单片机已经存在了很久。单片式Java项目是使用ANT和Maven构建的。第一步是精简你的构建。你还应该去除依赖关系和其他影响构建的外部因素。
解除依赖关系
一旦精简了构建过程，你就应该删除单体的模块化依赖关系。你可能需要重构你的代码来实现这种程度的解耦。
优化本地开发
构建、部署和测试应该在本地开发环境中以更快的速度进行。像Docker这样的工具也应该在本地被接受。这有助于加快操作任务，如设置本地数据库等。
平行开发
应该在代码库中创建多个分支，专门用于所有不同的微服务。这种设置将促进所有单体的平行开发，提高软件开发生命周期（SDLC）的敏捷性。
采用基础设施即代码（IaC
采用IaC将使基础设施更加统一和一致。使用务实的方法来构建环境，将极大地帮助开发者将云环境更接近他们的笔记本电脑。
9.微服务与单体。你应该选择哪个？
做出选择哪种架构的正确决定取决于几个因素。单体和微服务都有其优点和缺点。然而，在做出最终决定之前，你应该考虑到一些具体的因素。
技术能力
你应该考虑的第一件事是你对两种架构的熟悉程度。如果你决定转向微服务，你是否精通在这种架构上构建产品的所有做法？
团队
你的团队是否准备好接受和吸收微服务的原则？在采用微服务时，评估你的团队和你的产品的成长层面是至关重要的。
基础设施
在Docker和Kubernetes上运行的基础设施是最适合运行微服务的。实际上，如果你决定采用微服务，你应该有一个优秀的基于云的基础设施。
评估商业风险
微服务可能在各方面看起来都很正确，但它们会给业务带来风险。需要确定哪些领域需要扩展。如果你扩展那些现在不需要的部分，许多努力和人力就会白白浪费。关键的商业风险是由于微服务的垂直/水平扩展而可能产生的努力错位。
10.结束语
采用微服务是一种困难的方法。不是所有的架构都是一样的。同样，也不是所有的应用程序都是一样的。逐步采用微服务、相关技术和实践是关键。微服务对复杂和不断发展的应用程序更有利。然而，如果没有这些技术的适当专业知识，采用微服务将是一个巨大的任务。这篇博客给你介绍了微服务与单体的概况。最终，你需要找到在你的环境中运行良好的最佳方法。但不要担心，这就是我们在这里的原因
主题。
微服务、 单片机、 微服务与单片机、 架构分析
经Alfonso Valdes许可发表于DZone。点击这里查看原文。
DZone贡献者所表达的观点属于他们自己。
DZone上的热门文章
评论
