64 | 基于Spring Cloud的微服务架构
周志明
你好，我是周志明。
直到现在，由不同编程语言、不同技术框架所开发的微服务系统中，基于 Spring Cloud 的解决方案仍然是最主流的选择。这个结果既是 Java 在服务端应用所积累的深厚根基的体现，也是 Spring 在 Java 生态系统中统治地位的体现。
而且，从 Spring Boot 到 Spring Cloud 的过渡，让现存数量非常庞大的、基于 Spring 和 Spring Boot 的单体系统可以平滑地迁移到微服务架构中，让这些系统的大部分代码都能够无需修改，或少量修改即可保留重用。
在微服务时代的早期，Spring Cloud 就集成了Netflix OSS（以及 Spring Cloud Netflix 进入维护期后对应的替代组件）这种成体系的微服务套件，基本上也能算“半透明地”满足了在微服务环境中，必然会面临的服务发现、远程调用、负载均衡、集中配置等非功能性的需求。
不过，我个人是一直不太倾向于 Spring Cloud Netflix 这种，以应用代码去解决基础设施功能问题的“解题思路”。因为以自顶向下的视角来看，这既是虚拟化的微服务基础设施完全成熟之前，必然会出现的应用形态，也是微服务进化过程中必然会被替代的过渡形态。
不过，我的看法如何并不重要，基于 Spring Cloud Netflix 的微服务在当前就是主流，甚至直到未来不算短的一段时间内仍然都会是主流。而且从应用的视角来看，能自底向上地观察基础设施在微服务中面临的需求和挑战，能用我们最熟悉的 Java 代码来解释分析问题，也有利于深入理解微服务的整体思想。所以，把它作为我们了解的第一种微服务架构的实现，我认为是十分适合的。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
基于Spring Cloud的微服务架构是当前主流选择，尤其适用于平滑迁移基于Spring和Spring Boot的单体系统。本文深入介绍了Fenix's Bookstore的需求场景，并提供了多种运行程序的方式。作者强调了微服务架构的优势，如解决单体架构下的人力限制和技术异构需求。此外，文章还提供了通过Docker容器方式运行、通过Git源码以Maven编译运行以及在IDE环境中运行等多种运行程序的方式。技术组件方面，文章介绍了采用的Netflix OSS组件及其替代品，以及协议许可要求。总体而言，本文对基于Spring Cloud的微服务架构的特点和运行方式进行了深入浅出的介绍，对于想要了解微服务架构的读者具有很高的参考价值。
该试读文章来自《周志明的软件架构课》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
楊_宵夜老师好, 我想请问 aggregate 工程只有一个 pom.xml, 它的作用主要是用来干什么呢?作者回复: 为了执行jacoco-maven-plugin插件的report-aggregate任务，执行单元测试，并输出覆盖率信息。 课程中看不到覆盖率，在工程github页面上显示的“build:pass，coverage:81%”这样的信息就是通过这个工程自动产生的。
2021-05-032
公众号：业余草想问老师一个问题。假设我有一个部门表，然后有30多个页面（页面是表格）需要关联到部门信息。这里涉及到关联查询，每个页面除了部门信息外还可能包含其他表，关联表过多影响查询效率，这种情况下，如何处理好这些业务，实现相关功能？2021-04-2224- 楊_宵夜周老师好~ 有两个问题，想请问周老师有什么心得体会呢？ 1. Maven 多模块版本号管理 2. 在 Maven 多模块基础上，git 仓库的管理。 最近对关于 Maven 多模块管理的问题特别感兴趣，在Fenix's BS spring cloud 项目中，您使用了 Maven 多模块，但多个模块放在同一个 Git 仓库下。 1. 关于 Maven 多模块版本 Maven 3.5.0-Beta 版本后对多模块工程新增了${revision}关键字及相关插件去做整个项目的版本号管理。 如果使用${revision}，那么整个 FenixBS 就只有一个版本号，这样意味着就算其中一个微服务只改了一句代码，所有的微服务版本都会跟着升级并且 install 一次，意味着 maven 仓库中存在大量内容相同，仅仅只有版本号不同的 jar 包。（虽然这样并不影响实际开发及部署。 而如果不使用，则多个子模块间的版本号管理也是一个繁琐的问题。想请问周老师在这块实践当中的心得有哪些呢? 2. Git 仓库管理 另外 Maven 多模块在个人本地开发时确实是最佳实践。但到了 [代码 Git 仓库] 领域，又是另外一道风景。 举例来说，我司目前就无法使用多模块工程，因为业务繁杂，单个模块是由特定小组独立维护的。考虑到开发权限等各类问题，反映到 Git 仓库上，每个微服务模块有自己独立的 git 仓库。 针对这块本人也做了一些搜索，但网上资料非常少，只说到 Google, Facebook 等大公司是使用自研的代码仓库，并使用单体巨型代码仓库进行管理的。 Git 本身有相应的 Submodules 命令可以针对 Maven 多模块进行较好的管理, 但该命令相应的资料不多，并且为了日常开发的琐碎细节引入了 Submodules 这样更重的学习成本，这块是否值得？目前我们也不得而知。 希望周老师能答疑解惑, 感谢~2021-05-1111
收起评论