帝国网站怎么仿站,个人做旅游网站的意义,网站建设属于什么科目,深圳it外包服务模块化还是微服务#xff1f; 我们的业务由一个大型应用转向微服务的时候#xff0c;除了很好展示漂亮的PPT#xff0c;提升KPI之外#xff0c;实际操作时将整个业务切成微型服务似乎也不费吹灰之力。但这种方法真的是我们的最佳选择吗#xff1f;确实#xff0c;维护凌乱…模块化还是微服务 我们的业务由一个大型应用转向微服务的时候除了很好展示漂亮的PPT提升KPI之外实际操作时将整个业务切成微型服务似乎也不费吹灰之力。但这种方法真的是我们的最佳选择吗确实维护凌乱的单片应用程序有许多缺点。但是有一个令人信服的替代方案经常被忽视模块化应用程序开发。 在本文中我们将探讨这种替代方案的含义并展示它与构建微服务的关系。 什么是微服务 微服务现在越来越火爆但是到底什么是微服务Sam Newman在《构建微服务》中提供了对微服务的简洁定义是“微服务是一种小型自主的服务且相互之间可以协同工作。” 在《微服务架构》这本书中作者Mike AmundsenIrakli NadareishviliRonnie Mitra和Matt McLarty通过概述微服务应用程序共享的特征说明微服务的细节 体积小启用消息以上下文为界自主开发可独立部署分散使用自动化流程构建和发布一、模块化的微服务 “通过微服务我们最终可以让团队独立工作”或者“我们的应用太复杂这让我们放慢脚步”。这些表达只是导致开发团队走上微服务道路的众多原因中的一小部分。另一个问题是需要可扩展性和弹性。开发人员似乎总是渴望的是系统设计和开发的模块化方法。 软件开发中的模块化可以归结为三个指导原则 1.1强大的封装 隐藏组件内部的实现细节导致不同部件之间的低耦合。团队可以在系统的分离部分上独立工作。 1.2定义良好的接口 您无法隐藏所有内容否则您的系统不会做任何有意义的事情因此组件之间定义良好且稳定的API是必须的。组件可以由符合接口规范的任何实现替换。 1.3显式依赖 拥有模块化系统意味着不同的组件必须协同工作。你最好有一种表达和验证他们关系的好方法。 上述原则可以通过微服务实现。而微服务可以用任何方式实现只要它为其他服务公开定义良好的接口通常是REST API即可。其实施细节是服务的内部细节可以在没有全系统影响或协调的情况下进行更改。但微服务之间的依赖关系在开发时通常不是很明确导致运行时可能的服务编排失败。 因此微服务实现了重要的模块化原则从而带来了实实在在的好处 团队可以独立工作和扩展。微服务规模小重点突出降低了复杂性。服务可在内部更改或替换而不会产生全局影响。当我们从一个虽然有点臃肿应用程序转变为分布式微服务系统这其实带来了大量的操作复杂性。突然间您需要不断部署许多不同的可能是容器化的服务。出现了新的问题服务发现分布式日志记录跟踪等。现在更容易出现分布式计算下的错误了。接口和配置管理的版本控制也会成为一个主要问题。而且问题清单会一直增长下去。 事实证明微服务之间的连接与所有单个微服务的组合业务逻辑一样复杂。虽然整体代码库中的“意大利面条代码”存在问题但在这两者之间存在网络边界会使这些纠缠问题升级为彻头彻尾的痛苦。 ps意大利面条代码是非结构化和难以维护的源代码的贬义词。可能由多种因素引起例如易变的项目要求缺乏编程风格规则以及能力或经验不足。 二、模块化替代方案 这是否意味着我们要么被降级为凌乱的大型应用还是必须淹没在微服务疯狂的复杂性中模块化也可以通过其他方式实现。重要的是我们可以在开发过程中有效地绘制和强制执行边界。但我们也可以通过创建一个结构良好的大型应用来实现这一目标。当然这意味着我们往往会从编程语言和开发工具中获得帮助以实施模块化原则。 例如在Java中有几个模块系统可以帮助构建应用程序。 OSGi是最着名的一个但随着Java 9的发布Java平台本身就添加了一个本机模块系统。模块这种特性作为一流的结构现在是语言和平台的一部分。 Java模块可以表达对其他模块的依赖关系并在强大地封装实现类的同时公开导出接口。甚至Java平台本身一个庞大的代码库也使用新的Java模块系统进行了模块化。 其他语言提供类似的机制。例如JavaScript从ES2015开始获得了一个模块系统。在此之前Node.js已经为JavaScript后端提供了一个非标准的模块系统。但是作为一种动态语言JavaScript对实施接口类型和模块之间的封装的支持较弱。可以考虑在JavaScript之上使用TypeScript再次获得此优势。微软的.Net Framework确实具有类似Java的强类型但它在强大的封装和程序集之间的显式依赖性方面没有直接等同于Java即将推出的模块系统。尽管如此通过使用在.Net Core中标准化的Inversion-of-Control模式以及通过创建逻辑相关的程序集可以实现良好的模块化体系结构。甚至C 也在考虑在未来的版本中增加一个模块系统。许多语言对模块化越来越感兴趣模块化本身就是一个引人注目的发展。 当我们有意识地使用开发平台的模块化功能时您可以实现我们之前归因于微服务的相同模块化优势。从本质上讲模块系统越好在开发过程中获得的帮助就越多。不同的团队可以在不同的部分上工作其中只有明确定义的接口才是团队之间的接触点。但是在部署时模块在一个部署单元中聚集在一起。这样您可以防止与迁移到微服务开发和管理相关的实质复杂性和成本。当然这意味着无法在不同的技术栈上构建每个模块不过对大多数公司和开发团队而言真的能掌控好多个技术栈 三、设计模块 创建好的模块需要与创建良好的微服务相同的设计要求。模块应该模拟业务域的单个有界上下文。选择微服务边界是一项架构上重要的决策如果做错了会产生代价高昂的后果。而模块化应用程序中的模块边界更容易更改。类型系统和编译器通常支持跨模块的重构。重新划分微服务边界需要进行大量的人际交流以免在运行时爆炸。 在许多方面静态类型语言中的模块为定义良好的接口提供了更好的结构。通过另一个模块公开的类型化接口调用方法对于更改比在另一个微服务上调用REST端点要强大得多。 REST JSON无处不在但在没有编译器检查的模式的情况下它不是良好类型的互操作性的标志。更重要的是许多模块系统允许表达对其他模块的依赖性当违反这些依赖项时模块系统会禁止这样做至少会有个明确的提示但微服务之间的依赖关系仅在运行时实现导致难以调试的系统。 模块也是代码所有权的自然单位。团队可以负责系统中的一个或多个模块。与其他团队共享的唯一事情是其模块的公共API。在运行时与微服务相比模块之间的隔离更少。毕竟一切仍然在同一个进程中运行。 没有理由为什么单块中的模块不能像一个好的微服务那样拥有它的数据。然后模块化应用程序内的共享可以通过模块之间定义良好的接口或消息进行而不是通过共享数据存储区。微服务的最大区别在于一切都在进行中。不应低估最终的一致性问题。通过模块最终的一致性可以是一个深思熟虑的战略选择而不是无法避免的选择。对于微服务没有选择只能选择最终的一致性。 四、微服务什么时候适合您的组织 那么什么时候应该转向微服务到目前为止我们主要专注于通过模块化来解决复杂性问题。为此微服务和模块化应用程序都可以。但除了迄今为止提出的挑战之外还有不同的挑战。 当公司有Google或Netflix的规模时完全有理由接受微服务。这意味着有能力构建自己的平台和工具包并且工程师的数量也已经足够。但是大多数组织并没有以这种规模运作。哪怕是公司有一天会成为价值10亿美元的独角兽从模块化的大型应用开始也不会造成什么问题。 启动单独的微服务的另一个好理由是不同的服务本质上更适合于不同的技术栈。也就是锁必须拥有足够的规模来吸引这些不同的技术栈中的人才并保持这些平台的正常运行。 微服务还可以独立部署系统的不同部分这在大多数模块化平台中很难甚至不可能。隔离部署增加了系统的弹性和容错能力。此外缩放特性对于每个微服务可以是不同的。可以将不同的微服务部署到匹配的硬件上。模块化的整体也可以水平缩放但是更细微的就很困难。但是在一般实践中模块化这种方式可以支持很久的业务发展。 五、结论 如何选择其实取决于环境组织和应用程序本身。我们可以从模块化应用程序开始然后随时选择转移到微服务还可以使用模块在内部构建微服务。 如果我们追求模块化的好处请确保我们不要落入只能使用微服务的思维模式。尽可能的在最喜欢或者最擅长的技术栈使用内置的模块化功能或框架。 作者享学课堂Mark 转载请注明出处。 持续关注我分享更多干货。 转载于:https://juejin.im/post/5d0b55dc6fb9a07efe2dc316
