微服务迁移步骤建议

该怎样做,才能达成不盲目迁移服务的目标?建议按如下步骤,

1. 清理应用程序。确保应用程序具有良好的自动化测试套件,并使用了最新版本的软件包、框架和编程语言。
2. 重构应用程序,把它拆分成多个模块,为模块定义清晰的 API。不要让外部代码直接触及模块内部,所有的交互应该通过模块提供的 API 来进行。
3. 从应用程序中选择一个模块,并把它拆分成独立的应用程序,部署在相同的主机上。你可以从中获得一些好处,而不会带来太多的运维麻烦。不过,你仍然需要解决这两个应用之间的交互问题,虽然它们都部署在同一个主机上。不过你可以无视微服务架构里固有的网络分区问题和分布式系统的可用性问题。
4. 把独立出来的模块移动到不同的主机上。现在,你需要处理跨网络交互问题,不过这样可以让这两个系统之间的耦合降得更低。
5. 如果有可能,可以重构数据存储系统,让另一个主机上的模块负责自己的数据存储。

如果能够完成前面两个步骤,那么剩下的步骤一般不会像最初想象的那么重要了。如果在这个过程的某个点上停下来,而系统仍然具有可维护性和比刚开始时更好的状态,那么就再好不过了。

时间: 2024-10-10 04:06:36

微服务迁移步骤建议的相关文章

微服务迁移记(五):WEB层搭建(3)-简单的权限管理

一.redis搭建 二.WEB层主要依赖包 三.FeignClient通用接口 以上三项,参考<微服务迁移记(五):WEB层搭建(1)> 四.SpringSecurity集成 参考:<微服务迁移记(五):WEB层搭建(2)-SpringSecurity集成> 五.FreeMarker集成 参考:<微服务迁移记(五):WEB层搭建(3)-FreeMarker集成> 六.简单权限管理 实现一个简单的到按钮级权限管理,基于数据库扩展.不支持数据级权限,菜单只到二级(可以扩展至

从Spring Cloud到Kubernetes的微服务迁移实践

写在前面 要出发周边游(以下简称要出发)是国内知名的主打「周边游」的在线旅行网站,为了降低公司内部各个业务模块的耦合度,提高开发.交付及运维效率,我们在 2017 年就基于 Spring Cloud 完成了公司内部业务微服务化的改造,并在 2019 年实现了 Spring Cloud 至 UK8S 平台的迁移.? 本文从要出发的业务架构.Prometheus JVM 监控.基于 HPA 的峰值弹性伸缩.基于 Elastic 的APM链路跟踪及 Istio 服务治理等方面介绍了我们基于UK8S的

微服务迁移记(五):WEB层搭建(1)

WEB层是最终表现层,注册至注册中心,引用接口层(不需要引用实现层).公共服务层.用户登录使用SpringSecurity,Session保存在redis中,权限管理没有用SpringSecurity那套,自己写了一个简单的菜单.按钮权限控制.我在虚拟机192.168.0.7中搭了一个redis服务. 一.redis搭建 下载redis后,在linux下启动比较简单.需要注意的是redis.config配置: 1. 如果想配置用户名密码 requirepass 123456 2. 如果不bind

微服务迁移记(三):配置中心SpringCloud Config搭建

springboot推荐使用注解方式,减少了大量的xml配置.系统的基本配置文件我选择用yml格式,相对于properties,代码更简洁(不用重复写属性),结构化更清晰一点,读取速度也应该能略快一点吧.配置文件名bootstrap.yml优先于application.yml. 分布式配置中心,主要是将配置信息保存在配置中心的本地文件或数据库或远程版本控制中心(svn.git)中.研究了一段时间阿波罗,不知道为啥虚拟机能telnet宿主mysql,但阿波罗始终提示数据库连接不上,遂放弃.进一步研

微服务迁移记(四):公共层、接口层和实现层搭建

公共层Nodule:zyproject-common,通用返回体.状态码枚举.自定义分页类.本来计划Entity放在common里的,后来想了下,还是放到接口层,反正其他层也都会引用接口层. 接口独立成一个Module:zyproject-api-service,定义访问接口,供实现类.表现层调用,其中Feign接口直接继续接口层,可以避免很多冗余代码 实现层Module:zyproject-api-service-impl,与数据库打交道,实现接口. 一.公共层 通用返回体是从网上抄的,Res

从单体架构迁移到微服务,8个关键的思考、实践和经验

转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究.如需加入微信群参与微课堂.架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”.   随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多.去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上.毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix.Uber这样的公司都是非常成功的应用案例. 但需要注意的

微服务 - 文章

[微服务与容器的监控 —— 来自Adrian Cockcroft的挑战][http://www.infoq.com/cn/news/2015/07/monitoring-microservices]Adrian Cockcroft在GlueCon 2015大会上为听众列举了如何对微服务与基于容器的应用进行监控的多条规则.他还重强调了在监控cloud native并且基于容器的系统时所面临的挑战,并介绍了微服务模拟与可视化工具“Spigo” [微服务的好处][http://www.infoq.co

【转】技改之路:从单块应用到微服务,我的血泪总结

技改是技术改造的简称,是技术的蜕变.技术改造,对于公司和技术人员而言都非常难得,参与者多,主导者少.我有幸前后主导过3次OTA系统的技改,规模有大有小,每次环境和问题虽不一样,但还是有套路可循. <技改之路>少讲技术多讲路,我们不过多的关注技术细节和中间件的实现,而重点讲述技术改造的过程和思考,以下是本次分享的Topic: 系统背景 前期工作 技改实施 总结 1 系统背景 1.技术规模 公司 国内领先的B2B机票分销平台 资本原始积累,财务良好,一直盈利 系统规模 200+应用 100+库,1

微服务说的局限性

导读 关于微服务的优势和劣势已经有过太多的讨论,不过我仍然看到很多成长型初创公司对它进行着"盲目崇拜".冒着"重复发明轮子"的风险(Martin Fowler 已经写过"Microservice Premium"的文章),我想把我的一些想法写下来,在必要的时候可以发给客户,也希望能够帮助人们避免犯下我之前见过的那些错误. 在进行架构或技术选型时,将网络上找到的一些所谓的最佳实践文章作为指南,一旦做出了错误的决定,就要付出惨重的代价.如果能够帮助哪