单片机与微服务架构-使用哪个更好？

这是否意味着微服务比单片机架构风格更好？在这篇文章中，我们同时讨论了单片机和微服务架构。

什么是微服务架构以及为什么经常选择它

目前，软件范式由两类解决方案代表：微服务和单体架构。一般来说，微服务架构将一个应用程序表示为小型、松散耦合的服务集合。在这种解决方案中，复杂性被转移到服务的协调层面。每个服务代表一个业务能力，这使得代码的定位更加容易。

而单片式架构假设几个离散的功能组成一个单元，作为一个整体被测试、部署和扩展。所有的组件都是相互依赖的，往往不能单独运行。这也意味着一个模块中的错误会减缓或破坏整个应用程序。

微服务架构-优点和缺点

像每个解决方案一样，微服务架构也有其优点和缺点。

何时选择微服务

Martin Fowler（2015）就如何构建有用的软件给出了建议："几乎所有成功的微服务故事都是从一个单体开始的，这个单体太大，被打散了。"亚马逊开创了微服务架构。2001年，该公司发现自己无法跟上其快速增长的客户群的扩展需求。由于来自各种应用的无数请求，该公司面临着编码问题、开发延迟和服务的相互依赖。为了从头开始弄清其系统的重构，亚马逊将其单体应用分解为小型、独立的特定服务应用。一个服务接受订单，另一个服务生成一个推荐购买的物品清单，还有一个是简单的认证服务。

仅仅跟随现代潮流而选择微服务是错误的做法。然而，沉重的系统负载或与不同支付系统互动的必要性要求软件架构，以及代码的设计要支持它。

在某些情况下，转向微服务是企业的正确选择：

• 需要克服增长和扩展的挑战。如果你的单体应用已经变得太不灵活，无法升级。有系统中断和扩展的需要。
• 加快进入市场的时间。为了在竞争激烈的商业环境中取得成功，你需要快速开发和发布应用程序、更新和新的应用程序功能。
• 商业智能，人工智能。你需要实施先进的商业智能解决方案，以获得更深入、更有竞争力的商业数据、报告和分析。
• 物联网网络。你需要建立一个物联网网络，而你目前的基础设施不能提供所需的横向可扩展性，不能处理巨大的数据处理负荷。

转向微服务时的挑战

在从单体架构迁移到微服务架构的过程中，企业可能会面临一些挑战。采用微服务会带来技术和组织问题，了解这些问题确实很重要。所以，现在我们讨论一下风险。

• 它是非常困难和耗时的。你需要明白，单体的迁移会花费大量的时间和精力。这就是为什么面向微服务的重构应该分小部分进行。公司必须支付给开发人员，但事实上，该项目将不会被开发。如果你想在迁移过程中仍然开发新的功能，你应该仔细组织一个开发团队。
• 它是非常昂贵的。不仅从开发和编写代码的角度来说是昂贵的，而且从支持、操作和进行修改的角度来说也是昂贵的。它需要在建设基础设施、开发文档和重构应用程序方面进行大量投资。
• 微服务是一个分布式系统。这意味着开发团队需要选择和实现一种基于消息传递或RPC的进程间通信机制。
• 代码库的移动。从现有的单体中提取微服务对数据和代码库是很危险的。在重构过程中小心谨慎是非常重要的，因为有可能会引入新的错误。这就是为什么需要良好的测试覆盖率。
• 组织上的挑战。组织必须将大的团队分成小的团队，使其能够自主地工作。这样一来，组织的结构就与架构的结构一致了。
• 团队对他们的服务负责。团队拥有他们的代码库，他们负责服务的功能。而且他们不能把失败归咎于别人。如果产品有问题，团队必须解决它。
• 在不停止系统的情况下管理迁移过程。用户应该能够访问应用程序。

这些问题表明，微服务架构可能并不总是对初创公司和中型公司有利，因为它需要资源。

迁移-从哪里开始？审计和分析

从单片机架构迁移到微服务可能需要几年时间。你怎么知道它是否适合你的组织？Sam Newman是一本关于微服务迁移模式的书的作者，他为开发者提供了在采用微服务架构之前要考虑三个问题：

• 你希望达到什么目的？
• 你是否考虑过使用微服务的替代方案？
• 你将如何知道过渡是否有效？

在决定将单片机转移到微服务或改变架构之前，评估它对产品的必要性是非常重要的。正如我们所提到的，这非常昂贵和耗时，而且有很大的风险。基于Sam Newman的建议和我们的经验，我们提出一个分析方法。

设定目标

• 为什么你可能想要迁移，什么时候你不能避免迁移。
• 形成一套企业要实现的结果，并描述系统的终端用户的利益。明确迁移到微服务中你想获得什么。它可能是快速开发，或者你需要减少服务的相互依赖性，增加正常运行时间，或者可扩展性。
• 测量系统的预期负载和用户数量。

思考替代方案

• 关于迁移的决定可能与沉重的负载有关，那么你需要选择。
• 迁移部分功能。这取决于项目的情况。发送电子邮件、推送通知或电话的功能是不绑定的，可以被分割。但如果我们有一个仪表盘的系统，分析结果是从链接的数据库中收集的，这几乎是不可能的。
• 分析当前的功能并进行优化。重新考虑在主要项目上产生下载的原因：次优的数据库查询或大量不必要的信息。也许有必要更新硬件。开发新的功能并把它们带到微服务中。
• 尝试应用垂直或水平扩展。

评估你的DevOps团队的成熟度水平

你的团队需要了解核心DevOps实践。是否有一个普遍的自动化文化？你的运营团队是否支持脚本化部署？基础设施即代码的情况如何？你有关于如何进行代码审查的标准吗？如果你有成熟的开发和运营实践，那么微服务架构可能很适合你。

对业务功能和能力进行盘点

你的架构师应该找到相关的代码对象，并将它们与系统中的业务功能相匹配。许多功能不能被移动，因为它们的领域还没有被明确定义。技术团队必须了解将所有的功能划分为微服务有多大问题。例如，可能会有这样的情况：每个实体都与其他几个实体联系在一起。在这种情况下，不可能将其分割成一个普通的微服务。业务流程的逻辑可能会非常混乱。

确保你能摆脱依赖性循环

依赖性循环有时是无法避免的，但它们在服务之间建立了联系，然后模糊了它们的边界，并提出将它们合并成一个模块。

明确你是否可以创建跨职能的团队

他们应该包括开发人员、QA、操作员和业务所有者。微服务需要一个不同的指挥结构。创建能够设计、构建、部署和维护服务的团队，而不需要任何审批程序。"我们试图创建的团队，其规模不超过两个披萨所能提供的食物"。杰弗里-贝佐斯称之为 "两个比萨饼的团队规则"。

选择扩展平台

你需要能够为微服务扩展资源或支持自动扩展的软。作为一个解决方案的选择，你可以使用由云供应商（如谷歌云、微软Azure和亚马逊网络服务）托管的无服务器基础设施。

然后，你应该考虑如何建立一个不损害用户体验的流程。工程师与客户一起进行业务需求分析，构建业务逻辑的详细数据流。它不应该在迁移时被改变。

你决定要拆分-一步一步的说明

将单体系统迁移到微服务架构是一个复杂的问题，软件开发团队必须解决。现在我们总结一些关于如何采用微服务的经验和说明。

界限的定义

正确的微服务边界是健康的微服务架构的基础。在边界措施错误的情况下，一个新的微服务的功能变化会导致其他微服务的功能变化。因此，所有依赖的微服务的接口将在随后的集成测试中 "浮动"。而如果这些微服务属于不同的团队，就会面临团队间的会议和审批。

一个可能导致领域分离的生动例子是软件公司Istio。他们已经确认，他们正在从微服务架构向单体迁移，以便更容易地开发他们的产品，并以更少的努力满足一些业务需求。

迁移到微服务后，Istio团队开始从他们的用户那里得到反馈；他们很快意识到，微服务并不像他们最初想象的那样有用。主要原因是，所有的控制平面服务都是一起部署和使用的，并且共享相同的管理和安全域。因此，将Istio控制平面转移到单体架构是一个很好的决定，因为它大大降低了Istio的操作复杂性。所以，要确保单片机可以根据技术标准来打破。认识到架构内的业务领域边界，并使用公共API作为接口来执行。

突出单体中可以移动的功能

确定哪些功能组作为微服务提供最大价值是很重要的。其余的功能可以暂时留在单体系统中。一个由工程师和领域专家组成的团队将引导你了解现有的实现、依赖关系和内部事件。非技术专家会指出你的服务中所缺少的东西，或者将来可能是关键的功能。

为微服务提供独立的数据存储

每个微服务应该有一个数据存储库。注意，分离数据会使其更难管理。单独的存储系统很容易出现不同步或不一致的情况。因此，你需要一个能够执行主数据管理（MDM）的工具。比方说，它可以检查每个用户ID的数据库，以确保所有数据库中存在相同的ID。确保用户数据的安全，即使服务停止工作。最初，最好同时在微服务和单片机表中存储数据。

保留微服务的代码

与其在一个性能良好的已部署的微服务中添加或重写一段代码，不如为新的或改变的代码创建一个新的微服务。这样，你就可以部署和测试新的代码，而不用担心在现有的微服务中出现失败的风险。

为微服务单独构建

为每个微服务做一个单独的构建。这样，就有可能在适当的修订级别从存储库中获得组件文件。

在容器中部署微服务

要部署微服务，最好使用容器，这样你只需要一个工具。请注意，Docker被建议作为容器的标准。

避免 "雪花 "系统

将微服务器视为集团中可互换的成员。停止工作的那个会自动被另一个取代。避免 "雪花 "系统，不要依赖独立的服务器来实现专门的功能。

需要了解的一些案例

Netflix

主要原因。为了克服扩展的挑战和服务中断。早在2008年，一个错误导致了大规模的数据损坏，并导致了数天的停机时间。该公司需要一个架构，使Netflix能够全天候运行，扩展到下一个数量级，并优化速度。微服务架构允许Netflix将系统分成独立的服务：一个服务存储所有观看的节目，另一个服务负责每月的信用卡支付，第三个服务分析观看历史并提供类似的节目和电影。主要的挑战。完成迁移需要整整七年的时间。当Netflix第一次将面向客户的网站迁移到云端时，网页有很多延迟问题。AWS美东地区曾发生过一次故障，导致托管在AWS上的几个热门网站瘫痪。最佳实践。Netflix决定放弃纵向可扩展的单点故障，如我们数据中心的关系型数据库，而选择云中的高可靠性、可扩展的分布式系统。他们选择了亚马逊网络服务（AWS）作为云供应商，因为它提供了最大的规模和最广泛的服务和功能。Netflix使用NoSQL数据库对数据模型进行规范化。

Wix.com

主要原因。为了扭转造成严重稳定性问题的大量技术债务。由于应用程序是相互连接的，系统中的一个部分的错误有可能使我们的整个系统崩溃。主要的挑战。处理微服务之间的通信问题，解决故障和调试问题 最佳实践。发明新的集成和端到端测试模式，并围绕这些准则培养一种新的内部文化。实现自己的JSON/RPC协议，并在SpringMVC之上建立一个微服务框架。

云元素

主要原因。为了应对一个 "超增长公司 "的需求。对于一个正在经历指数级增长的公司来说，微服务的设计有助于不断迭代以适应新的需求。

主要挑战。组织变化。由于组织结构中的沟通差异和围绕微服务的内部沟通，出现了许多意见和冲突。

最佳实践。使用此类工具，如Minikube和Docker，有助于在本地运行服务并远程运行。所有的微服务都在Node.js中；因此，他们利用基于npm的软件包，如Ava用于单元测试，NYC用于伊斯坦布尔的代码覆盖模块，以及XO用于刷写。

最佳购买

主要原因。相互依赖的架构成为部署的一个问题。停机时间太长，无法维持在线开展业务 主要挑战。建立信任。对软件的构建和部署方式存在文化阻力。团队习惯于将一个又一个的功能打包到不经常发布的版本中，然后他们不得不处理他们工作方式的改变。

最佳实践。CI实施和部署工具，如Chef和Jenkins。然而，最大的变化是转移到Riak，一个分布式NoSQL键值数据存储。

结论

那么，我们应该跟上新的架构决策还是继续保持单片机？实际上，没有最终的答案。微服务架构既不好也不坏，它只是构建软件的一种不同方式。这个决定取决于应用程序的业务需求。

客户和开发团队必须找到一个共同的解决方案。比方说，项目没有计划高负载和与外部服务的互动，在这种情况下，最好选择单体。另一方面，如果系统必须在任何负载下工作，并有大量的服务，那么微服务架构是最好的选择。

这在很大程度上取决于你企业的组织结构。你是否有几个IT团队在同一个产品上工作？微服务可能是合适的。但如果你有一个由几个开发人员组成的团队，他们会很好地建立和维护单片机。

这取决于你的决定，只是要确保你的解决方案是合理的。在某些情况下，从单片机开始可能会更容易。让你的服务在单体应用中成长，然后才开始将它们转移到独立的服务中。选择权在于你。