市政浙江建设培训中心网站,网站挣钱方式,保定百度推广联系电话,织梦网站模板制作微服务仅适用于成熟产品
关于从头开始使用微服务#xff0c;马丁・福勒#xff08;Martin Fowler#xff09;总结道#xff1a;
1. 几乎所有成功的微服务都是从一个过于庞大而不得不拆分的单体应用开始的。 2. 几乎所有从头开始以微服务构建的系统#xff0c;最后都会因…微服务仅适用于成熟产品
关于从头开始使用微服务马丁・福勒Martin Fowler总结道
1. 几乎所有成功的微服务都是从一个过于庞大而不得不拆分的单体应用开始的。 2. 几乎所有从头开始以微服务构建的系统最后都会因严重的问题而失败。这种情况导致许多人认为就算你确信你的应用将快速发展壮大也不应该一开始便采用微服务。
初版设计很难优化得很好新产品的前几次迭代重点在于寻找用户的真正痛点。因此成功取决于保持敏捷并能快速优化和重构。在这方面微服务就比单体应用差得多。如果你没有把握设计好最初的方案就采用了微服务那么你的启程之路将更加困难因为重构微服务比重构单体应用要困难得多。
微服务不是本地部署的最佳选择
由于所有部件都是动态变化的微服务部署需要搭配更强大的自动化机制。在常规环境下我们可以依靠持续部署管道continuous deployment pipelines来完成工作 —— 任务开发者部署微服务消费端尽管使用线上服务就可以了。
然而这并不适用于本地环境如果开发者发布一个包需要消费端自行在其本地环境上部署和配置其他的服务这使得部署变得更具挑战性。
确切的说开发本地微服务应用也是可行的正如 Semaphore一个 CI/CD 平台也提供了本地化部署模式。然而在这个过程中我们需要克服几个挑战
1. 本地微服务的版本控制规则需要更加严格你必须跟踪参与发布的每个单独的微服务。 2. 你必须进行完整的集成和端到端测试因为你无法在生产环境中进行测试 3. 如果不能直接访问生产环境对微服务应用进行故障排查会困难得多
模块化单体或许是更好的解决方案
开发人员想要避免采用单体架构的一个常见原因是单体更容易变成一坨 “代码屎山”。那时很难再添加新功能因为一切都是相互关联的。
但是单体不一定是一团糟。以 Shopify 为例他的代码行数超过 300 万行是世界上最大的 Rails 单体应用之一。但有一点系统过于庞大会给开发人员带来许多痛苦
应用非常脆弱新的代码会产生许多意想不到的影响。作出一些更改可能会引发一连串无关的测试用例失败。例如计算运费和计算税率复用了一些代码那么更改计算税率代码的同时可能会影响运费计算的结果。这是高耦合和缺乏边界的结果也导致测试用例难以编写并且在 CI 上运行得非常缓慢。
Shopify 没有选择将整个单体应用重写为微服务而是选择了模块化作为解决方案。 模块化有助于设计更好的单体或者微服务。如果没有认真地定义好模块我们要么陷入传统的分层式单体大泥球或者更差的结果成了分布式单体应用它同时具备单体和微服务两者的缺点。
模块化的工作量很大但它也带来了巨大的价值使开发可以更加直接。新开发人员在开始变更代码之前不必了解整个应用一次只需要熟悉一个模块。良好的模块化可以使一个大单体更好上手。
模块化是切换到微服务之前的必要步骤并且有可能是更好的解决方案。与微服务类似模块化单体应用通过将代码拆分为一些独立的模块来解决代码耦合的问题。与微服务通过网络进行通信不同单体应用中的模块通过内部 API 调用进行通信。
分层式单体对比模块化单体模块化单体具有微服务的许多特征却没有微服务面临的诸多挑战。
如何快速模块化单体
如何快速模块化单体采用小程序容器是最简便的方案。不如 FinClip 提供的可插拔式的技术工具这是一种以小程序技术为载体发展成模块化的企业应用架构技术。
从应用层来说只要把 FinClip SDK 嵌入到企业的 App 中就能立刻获得小程序运行能力。不管你的项目是什么软件架构都可以通过这种嵌入式的小程序技术去获得 APP 并行开发、热更新、敏捷迭代的能力。
小程序容器和单体架构的结合可以实现前后端分离。前端开发者可以专注于小程序的界面设计和交互逻辑而后端开发者可以专注于服务的实现和数据处理两者之间的接口通过网络来进行交互。这种方式可以提高开发效率和部署速度同时也可以降低应用程序的耦合性和维护成本。
从开发角度来说这是一种「Native 小程序」的混合开发模式借助这种模式可以让小程序运行在自有 App 中将臃肿的 App 功能打散功能模块互相解耦实现模块化开发各业务模块间互不影响通过管理后台即能实现实时动态更新与发布。对于一些积重难返的项目来说采用这种入侵性小、可插拔式的技术是一种值得尝试的解决方案。
