武汉佰钧成心得分享:微服务架构的搭建与改造
对于中小企业来说,使用微服务架构来应对产品迭代压力是个不错的方案。它能快速承载海量用户访问的压力,同时搭建起来也十分方便。但如果想要实现微服务切换,过程中依然会产生一些问题,到底应该如何解决这些问题呢?武汉佰钧成在微服务架构的搭建及改造方面已积累了许多经验,今天就来对此分享一下心得体会。
武汉佰钧成心得分享——旧系统升级为微服务架构
【武汉佰钧成心得分享:微服务架构的搭建与改造】将旧系统升级为微服务架构的前提是不影响现有业务,因此需要根据当前的业务状况出发,以此为基础来制定方案。以下将举例说明:
现状一:旧系统功能还算稳定,技术相对较老旧
文章插图
实施策略:优先重构基础数据放缓存,为提供给微服务做准备;改造权限数据和实现sso与网关对接,同时处理好web端跨域调用;逐步绞杀对应的业务模块,迁移相应的数据表,业务聚合性较强的整合在一起;最后把基础数据,权限数据全部微服务化。
现状二:旧系统一直在不停的需求迭代
文章插图
实施策略:最合理的策略是先停止往单体式应用里面添加新的特性,所有新特性都构建成微服务,从而遏制单体式应用继续生长。同时要建立旧系统和微服务之间的防腐层,避免旧系统在升级过程中功能维护对微服务产生腐化。借助这个过程让团队逐渐熟悉掌握微服务技术栈,从小规模练兵再到全面铺开。
武汉佰钧成心得分享——微服务架构的改造
旧系统改造的过程中经常遇到需要将数据进行切换,例如由原来的oracle转换成mysql,或者由sqlserver转换成mysql等,这种改造首先要进行分析,如果有存储过程,函数等,优先实施完成后再进行切换。优先模式是逐步切换和迁移,不能进行一刀切。
拆分微服务前就要充分考虑服务调用问题,尽量避免多个服务调用,避免分布式事务,尽量不做调用链很长的模式,如果一定要存在多服务调用,建议用事件机制解耦,或者通过mq,redis等中间件处理,不要存在长调用链或者强一致性业务多服务调用的情况出现。
文章插图
在改造过程中还会遇到一些报表数据的处理问题。简单报表服务间做数据冗余,再结合redis的基础数据来实施,复杂报表需要跨多个服务的建议将数据聚合并清理成具体的报表模型,由es来提供服务是比较稳妥的方式。
微服务架构固然实用,但它也不是没有缺点的。就目前而言,微服务架构的搭建难度不大,但对使用场景有要求,也有一定的落地难度。因此武汉佰钧成建议,提前根据具体业务情况做好规划,结合已有的系统来使用它,并做好微服务架构与单体架构长期共存的准备。善用微服务架构,它便能发挥出应有的功效。
- 武汉|武汉TCL华星柔性屏出货量全球第四
- 武汉|纸箱疯狂:诞生中国第一个女首富,电商一年要发百亿件
- 小米科技|小米又在武汉设立新公司,注册资本20亿
- 武汉|“苹果”横扫中国市场,国产手机全军覆没,爱国只值1000块?
- 聚酰亚胺膜|可折叠手机屏基础材料率先在武汉量产
- 节点|国家顶级节点(武汉)里程碑成果发布,累计标识注册量 58.54 亿
- 电子信息制造|“5G + 工业互联网”全国电子信息制造业现场会在武汉召开
- 武汉东湖新技术开发区管委会|“星火?链网”超级节点(武汉)正式上线,开始向全球进行服务
- 国企网|亿达中国武汉软件新城园企安天移动安全获颁vivo 2021年度“最佳安全服务供应商”
- 36氪5G创新日报1118|武汉首座5G智慧公园下月将开门迎客;爱立信完成IMT-2020(5G)系列测试 | 5g+