中大型企业框架成长之路

前言

引用百度coo最近分享的一句话“一个优秀的程序员，要相信世界是由技术驱动的”。

背后的故事

2015年对于我来说是一个特殊的一年，待了五年的大城市已经感觉到疲惫，2014年底已经决定深圳回长沙，和大部分人的想法一样大城市没有归属感，想离家近一点的地方，准备前往长沙找工作，这个时候前公司的领导打电话给个我，说现在有个很好机会，一个大项目正需要大量人员，是新的框架技术，这下我新动了，大、新。。。哈哈，于是乎又前往我大深圳了。
来了之后很顺利的入职了，公司属于上市公司规模还比较大，但是信息化建设还比较落后，自主研发的信息系统基本没有，最核心的erp也是用的德国的，费用更加不用说了，集团领导下了决心，建立集团信息中心负责研发，这就说招我们的这批人的目的。在技术总监的带领下搭建了第一期项目框架雏形。

V1.0所涉及的技术（2015）

• 项目构建maven
• 开发语言java、基于spring、springMVC
• ORM持久化框架MyBatis
• 前后端数据交付FastJson
• 数据库连接池管理BoneCP
• 代码管理Git
• 数据库分片中间件MyCat
• 数据库监控，天兔数据库性能监控
• 项目构建发版jenkins
• 前端基于ExtJS
• 数据传输中间件自主研发DTS
• 登陆授权体系:cas、shiro
• app也说基于原生安卓开发
• 调度中心自主研发blf1-scheduler
• 负载均衡nginx
• 运维、手动参与
• common-core实现了大部分的基础功能包括单表的CURD、多表保存、单据的审核、导入、导出、打印等功能，一个简单的模块基本通过代码生成器生成就可以用。
• 。。。

总结：我们用这套框架开发了30几个应用系统，时间是我们最大的挑战，一边项目进度要达标，一边框架还在不断优化改造，所以整年对我们来说是辛苦对，通宵加班也是经常有的，但是值得的，在规定的时间内我们把德国的系统切换掉，换上了新的系统，得到了集团领导高度评价，同时我们自己也知道还有很多工作是需要改进的，当时为了赶进度留下来的问题，比如配置是存在服务器的固定目录、程序发版是半自动化、等这些问题。

V2.0所涉及的技术（2016）

• 数据库连接池管理BoneCP==>druid
• 文件存储Mongodb
• app也说基于h5来开发

在V2.0的框架我们主要做了三件事情

• 从新梳理cas、shoir体系，在1.0中我们是不支持多台服务器直接session共享、cas不能集群1.0采取的方案是在nginx采取ip负责模式来规避了这个问题，2.0中我们采用的用rdeis来存储ssesion。
• 引入了百度的disconf分布式配置中心，把所以的配置文件集中管理，大大减轻了运维人员的工作量
• dubbo引入，1.0模式各个工程直接数据调用都是用http请求，效率很低，经过综合考虑将dubbo引入，这样就解决在数据传输这方面的问题

总结：系统框架持续优化中，系统基本稳定，但是随着我们的业务工程越来越多，具体统计工程数量已经达到了100多个，服务器数量也多达50几台，运维人员管理这些机器有些吃力了，这也是我们在下一个框架中重点考虑的方向。

V3.0所涉及的技术（2017）

这次版本是具有革命性的变化来，这几年是微服务高速发展的黄金时间，这得益于spring团队推出Springboot、Springcloud两大框架，框架刚刚面世受到追捧，我们前两年没有时间弄这块，也没有这个技术能力，但正是经过这两个都发展沉淀我们已经有来这个底气，在技术总监的推动我们正式开启来我们微服务之路。

• 项目全部用Springboot来构建
• 配置中心用Springcloud-config
• 注册中Springcloud-eureka
• 网关中间Springcloud-gatway
• api之间调用fegin
• 分布式链路追踪Skywalking
• Springcloud等。。。
• 调度中心 lts+自主研发
• 采用gitflow发版流程
• gitlab用审查代码
• 全部应用采用docker部署
• 建立Kubernetes集群
• elk日志收集

总结：我们现在整个系统都是运行在docker环境，大大提高了服务器都利用率、将之前都服务器数量大大压缩为公司节省了成本、同时也解决运维人员之前发版难的问题、部署环境难的一系列问题。

V4.0所涉及的技术（2018）

目前还在研发中后续更新。。。