我们与微服务的纠缠的这些年

   日期:2020-10-13     浏览:92    评论:0    
核心提示:2013年正式介入软件开发,海域无人机系统OSGI+南网一级主站SSH双框架起步,直接扯着蛋上天了2014年,引入maven,考试系统尝试2016年废弃OSGI,引入jenkins,四川应急测绘指挥系统转向Springboot+jpa,与外协合作接触docker,尝试docker化2017年,海域综合监控分模块拆分,形成分布式系统,自己实现了类似于Feign的通讯工具类同年,贵州二级主站的实时监控分系统,Spring boot+eureka+config+nginx2018年,无人机系统重构,借助

前言

现在已经到了一个后端开发人员如果说自己没搞过微服务就out的时候了,前一段时间参加公司组织的微服务的相关培训,正好借着这个机会把我们这些年的微服务迁移过程梳理一下,要不然过一段时间也许这些过程就真的成为黑历史无人知晓了。

时间轴

微服务技术栈迁移过程

  1. 2013年正式介入软件开发,UAV系统OSGI+NFDW系统SSH双框架起步,直接扯着蛋上天了
  2. 2014年,KSXT系统,尝试引入maven
  3. 2016年6月,SCU系统,废弃OSGI,引入jenkins,转向Springboot+jpa,开始服务切分,与外协合作接触docker,尝试docker化,对接类和配置实现服务路由
  4. 2016年10月,ZHJK分模块拆分,形成分布式系统,自己实现了类似于Feign的通讯工具类
  5. 2017年,GZ-SSJK,Spring boot+eureka+config+nginx,形成为微服务的雏形
  6. 2018年,UAV系统重构,借助Spring boot+eureka+config+nginx+Dashboard+zipkin形成微服务雏形
  7. 2018年,HSMB系统,SpringCloud全家桶,config+euerka+zuul+feign+mybatisplus+k8s,在开发环境下搭建了整套的基于k8s的CI/CD集群,发现计算资源不足
  8. 2019年,DXAL系统,SpringCloud全家桶,config+euerka+zuul+feign
  9. 2019年,ISS系统,SpringCloud全家桶,config+euerka+zuul+feign
  10. 2019年,GX-SSJK,直接复制GZ实时监控
  11. 2020年,UMP平台,nacos+zuul+feign+k8s+skywalking+Prometheus
  12. 2020年,YN-SSJK,纯镜像化+docker-compose
  13. 2020年,SBH-SSJK,多模块化改造+纯镜像化+docker-compose
  14. 2020年,JGDQ系统,nacos+zuul+feign+docker-compose
  15. 2020年,DC系统,返回模块化的单体应用

架构演变过程

原始阶段

UAV架构

PS:IDE运行
NFDW架构

雏形阶段

SCU架构,单体应用+分布式雏形

ZHJK架构,分布式系统+注册中心+配置中心

成熟阶段

SBH-SSJK架构,彻底服务化

回归阶段

DC架构,单体应用


一个jar包直接搞定,

微服务的坑

  • 缺乏必要的理由
    为什么要进行微服务改造,相信业界已经有不少大佬说过了,但他们的原因对于你来说是否真的合适。
  • 基础服务准备不足
    最开始SCU系统纯靠手工部署,六七服务已经能把人搞得要崩溃了,由于服务之间又有一定的依赖关系,启动顺序也让人抓狂,这也是后来上docker-compose与k8s的原因,微服务的构建一定要依赖基础设施完成的,要不然iDE切项目来一个个构建真的是要疯了,纯手工的情况下,开发环境下没有32g机器根本启动不起来,这也是引入jenkins和docker以及harbor的原因。
  • 服务拆解的过细
    在微服务化的拆解过程中,SSJK以及UAV-Reborn按照惯性思维进行的拆解,形成了10多个服务,但是开发人员只是有三到四个人的情况下,完全hold不住,开发进行的非常快,但测试和部署非常费劲,除了问题排查难度极高。
  • 技术培训没有跟上
    还是刚刚UAV重构前要是能够对开发团队进行一次为期三到四天的微服务整体性的培训局面绝对将不一样。
  • 当你手上只有锤子的时候,看什么都是钉子
    不要啥事都要上微服务,小心上瘾。

到底什么样的情况适合微服务

  1. 你的项目是一个长期维护的系统,且维护最好由你的团队来进行,如果你的系统每次都是领导参观的时候才启动一次,那不如搞一个虚拟机部署好。
  2. 足够的硬件资源能够支持你的基础设施,最好由专门的基础平台团队来支持,开发环境包括但不限于,持续集成系统,版本控制系统,k8集群,开发节点,测试节点,日志聚合节点,skywalking节点,监控节点,数据集群,生产环境除了部署机器外,还要拥有监控集群,日志聚合和分析集群,日志追踪集群,这个对于互联网来说其实问题不大,毕竟云原生时代已经来到,但对于ToB企业来说挑战可不小,由于各种各样的原因可能是与互联网隔绝的环境,光是搭建研发环境就够崩溃的,至于如何能把服务部署到用户那就更是一门学问了。
  3. 你的研发团队拥有足够的能力能够hold住微服务的技术栈,如果你的团队只有五个人,但是要hold住25个服务,那只能希望你的成员都是阿里的水平而且异常稳定。.

下一步

  • 添加日志聚合分析
  • 简化用户环境的部署与升级过程

也许更好的做法

掌握微服务技术栈,项目启动时做好容量评估和架构演进设计,实施过程注重模块切分和解耦合,保证能够在必要的时候将应用转向微服务架构。

 
打赏
 本文转载自:网络 
所有权利归属于原作者,如文章来源标示错误或侵犯了您的权利请联系微信13520258486
更多>最近资讯中心
更多>最新资讯中心
0相关评论

推荐图文
推荐资讯中心
点击排行
最新信息
新手指南
采购商服务
供应商服务
交易安全
关注我们
手机网站:
新浪微博:
微信关注:

13520258486

周一至周五 9:00-18:00
(其他时间联系在线客服)

24小时在线客服