月度归档:2019年06月

建设企业统一开发平台设计思路,提供类平台化SaaS研发平台

一、背景背景

近年来,在政策和市场的双重拉动下,中国软件市场保持了持续快速的增长。2002年,中国软件市场实现了21.1%的增长率,销售额达到345 亿元。2003年,中国软件市场销售额达到400亿元左右,软件市场进一步升温。在几百亿元的市场规模下,掩盖了这样一个事实:软件项目成功率非常低。根据统计,超过80%的项目不能在最初估计的预算和进度内成功交付。这对用户和厂商都产生了严重的影响,对于软件产业的健康成长也非常不利。用户对厂商的效率和能力产生怀疑,对使用软件的效果产生怀疑。

厂商在项目过程中难以维持健康的现金流和获得足够的利润,无力提升产品研发水平和效率。业界一直在试图解决这种恶性循环,解决方法一是靠软件工程,厂商采用更科学、更规范的流程组织项目开发,如软件生产过程中的CMM(软件成熟度模型)规范;二是靠软件技术。而就软件技术而言,平台化技术是软件产品发展的重要趋势,平台化的软件具有独立性、开放性、可管理性和可扩展性等特点。

平台化软件分为技术支撑型平台和应用实现型平台。技术支撑型平台的用户为软件开发人员,提供商负责平台的维护和升级,用户负责基于平台的上层实现。这类平台包括软件中间件、开发工具、应用服务器等。应用实现型平台的用户为终端用户,提供商不但负责平台的维护和升级,还要负责实现基于平台的上层应用。

 例如:一个网站使用应用服务器WebLogic为技术支撑型平台,服务器的提供商(BEA)不会负责具体网站内容的建设。而应用实现型平台(如集尔普的Our-ERP系统)不但负责平台的维护和升级,更重要的是负责上层应用的实现,如企业管理软件中的财务管理,进销存,校园管理中的总务管理,教务管理等。本文章主要描述应用开发型平台的目标,定义,技术架构,实现和应用前景。

二、为什么要建设这样的统一研发平台

企业各产品系统独立开发,代码复用率低,系统之间互相调用,耦合严重,系统解耦独立部署困难。

应用间数据复制严重,数据不一致性严重
基础组件薄弱,日志,监控系统不完善
功能模块定义混乱,包含大量接口,接口定义重复
大容量访问下无法提供可靠性服务

待解决问题

核心系统全面服务化:系统分解为核心服务和基础服务。
基础组件:服务化框架,分库分区,缓存组件。
加强监控,日志系统。
步化并行,限流,分流,降级,压力测试,异地灾备。

建设的平台价值

这个基础平台以先进的技术作为依撑,采用服务架构实现一个共享可复用的统一框架,是具有扩展性、兼容性、前瞻性的底层平台,满足快速开发、避免重复开发的需求,开创产品创新的新模式和新途径,更好的为产品开发和部署、运维提供服务。

平台共享数据为各个子系统共同调用的数据,减少各子系统间数据的调用,减少系统间的耦合性,达到“强内聚,低耦合”的效果;
可实现数据一次输入,多个子系统使用,消除信息孤岛,减少数据库服务器工作量,提高整体使用性能;
提供统一的开发框架,提高开发效率,避免重复开发,节约成本;
便于部署,实施和运维;
形成一个产品,用于后期产品的开发和管理。
服务模块化设计,便于根据需求组合使用。
服务统一注册、发现、治理。
便于集群部署和负载均衡,提供强大的并发支持和高可用。

约束条件

系统稳定、高效,可支持内外各种不同使用场景下的并发操作。
良好扩展性:在增加新的功能时旧有模块不做改动或稍作改动即可完成集成,部署更新不影响其他业务。
提供数据接口:便于其他产品或第三方厂商系统进行集成。
模块化:各个功能部分按模块开发,模块彼此解耦。
配置化:可根据客户实际需求,配置不同参数。支持6大平台的开发和运行,支持Windows和Linux系统。
采用B/S架构,与外部业务系统之间使用RestfulAPI进行交互和开发。
需要支持高性能、高并发、高可用和高稳定的需求。

三、云开发平台与传统的研发企业平台有什么区别

平台化开发是一套综合的工具和一组实践证明的共享的最佳平台,它形成了完整、久经考验、开放和模块化的解决方案,旨在随需应变世界中开发软件和基于软件的服务。这一平台使开发小组能够跨合作伙伴、供应商 和客户自动化和集成软件开发的核心 业务流程 ,为企业提供获得竞争优势需要的灵活性和速度,从而能够 创新 和迅速响应市场变化。

平台化开发提供给企业将应用程序和业务流程演进到电子商务随需应变环境需要的所有工具。其核心是称为的面向大小型项目的灵活的流程架构。

传统的研发配置在本地开发配置,出现很多弊端,如:

环境不统一,编码版本和规范不统一;
非功能性需求产生技术问题占用一定时间,而且每个项目环境都不一样,开发过程耗时;
项目技术学习成本高,技术不统一,产生问题排查时间较多,影响工期;
没有统一的管理平台,产物得不到沉淀

云开发平台的优势在哪里

完成企业管理和规划的统一性,编辑规范的统一;
具备灵活方便的二次开发能力;
做到硬件独立和软件环境独立;
实现上层应用的技术无关性;
工作流、报表图表工具等也应与应用开发工具组合在一起,提供一个支持管理应用开发的平台;

平台化开发的优势

最大化效率:

开发平台可以帮助IT和工程小组用较少的资源来最大化输出、减少混乱和提升提供高质量的软件和与软件相关的系统的可预测性。

平台化开发通过符合行业标准的开放平台来加速价值的转化,它定义、集成和自动化软件开发的业务和流程。它还提供完整的建立、集成、现代化和部署软件的端到端平台,通过减少混乱和增加可预测性来提高效率。

增加业务灵活性:

开发平台由灵活的流程和一组定制用于任何项目或小组规模的产品组成。通过自动化和集成软件开发的核心业务流程,开发平台可以帮助您突出重点、灵活和迅速响应。

企业可以利用对大多数开发(模式、语言、操作系统和中间件)的支持,允许在企业内大范围重复使用流程、技能、生命周期工具和资产,以响应瞬息万变的业务环境。开发平台可以提供行业中最好的分布式地理位置的开发功能,支持现场开发、场外和境外开发、全球资源规划和远程数据工具。

缩短投资回报时间:

软件开发平台允许您实施四个强制性的随需应变软件开发流程:迭代开发、关注架构、管理变更和资产、持续的确保质量。实施这些强制性流程有助于加速IT和工程投资的价值实现 。

四、平台的市场和应用前景

设计良好的平台化软件应可以普遍应用于企业管理系统、校园管理系统、电子政务、医院管理系统等各行各业。企业管理软件中的销售与分销管理、生产管理、库存与采购管理、客户关系管理、办公自动化、人力资源管理等系统可以完全集成为一个系统,所有的企业资源(人、财、物)全部共享,全面降低企业的运营成本。

校园管理系统中的总务与后勤管理、教务管理、办公自动化、注册与离校系统可以集成为一个系统,实现学校的集中式管理,严格控制支出和消耗。医院管理系统的收费与挂号、财务管理、住院管理、医生站护士站等可以集成为一个系统,实现快捷、方便的医院管理。

2002年初,Gartner公司(ERP/MRPII理论的首创者)在对未来软件架构发展报告中认为平台化软件是管理软件的发展趋势。目前,由于平台化软件不可替代的优越性,SAP、Oracle等国外管理软件公司的产品都已经转向平台化,许多国产管理软件开发商都在宣称要将战略重点转向平台化软件,甚至宣称自己现在的产品就是平台化产品。

进入2004年以后,第一代ERP悄然消退的趋势更加明显。笔者认为,真正的平台化产品不应该在原有的固化的软件基础上的改造,因为原有的系统使用硬写代码的方式实现,无法与新型的平台化软件的运行支撑系统和应用开发工具结合,实现客户个性化需求的免编程定制。新型的平台化产品必须具备两个基本要素,实现应用的完全可定制,而不是原有系统外围的所谓“二次开发”。

由于平台化软件有着诸多优点,许多软件公司准备研发类似产品,十分关心产品研发需要注意的问题。根据统计,平台产品的研发壁垒有三个方面:一是投入资金大,一般一期的产品研发至少要3000万元,而完成成熟产品需要投入近亿元;二是研发周期长,需要2-3年的时间;三是核心技术壁垒高,需要软件技术人员、管理专家的集体参与。

随着中国软件产业的发展,国产管理软件在平台化软件技术和产品上已经有了很大的突破,许多过程的平台化软件产品已经能够与国外软件公司的产品保持同步,这必将给国内众多企业用户带来更大的效益。

五、平台的收益点和盈利点在哪里,怎么样可以提升收益

六、平台怎么做好进一步的运维和管理工作

开发为什么要从零开始搭建属于自己的统一研发平台和中台架构

从零开始搭建的意思,就是从需求分析,系统规划,设计分析和落地实践几个步骤,从无到有的过程。考虑左右,为了个人学习和提升,选型基于流行的springboot+springcloud,从零开始搭建一套自己用于学习的研发平台。

整体平台的流程,从管理、开发、测试、运维、生产几条线,实现整体平台的落地和管理,下面是整体研发平台架构。

整个研发平台架构设计

整个研发平台产物:https://gitee.com/landonniao

整体研发平台使用的基线规划如下

平台所有基线及所有项目目录结构,整体从零开始进行平台基线搭建及规划,多个基线的规划,考虑更合适多个岗位角色的管理

序号基线说明基线地址维护人员状态备注
1平台整体文档目录alinesno-cloud-document集成中
2平台环境搭建文档记录文档基线alinesno-cloud-evn集成中
3平台前端规划及页面基础页面设计基线alinesno-cloud-pages集成中
4平台所有服务列表代码基线alinesno-cloud-service集成中
5平台前端应用和手机应用代码基线alinesno-cloud-application
6平台自动化测试基线alinesno-cloud-test
7平台运维脚本过程产物基线alinesno-cloud-operation
8平台搭建过程中常见问题基线alinesno-cloud-question
9开发人员使用平台指引alinesno-cloud-guide

一、个人为什么要搭建一个统一研发平台

1、为了有方向感,不迷茫,不浪费时间,有可行的学习计划

上大学的时候,就开始学习计算机,从基础的Java到Java web,再到框架,再到在学校接一些小项目,如企业网站,兼职网,报名网站等,这几步路大概走了2年左右,而在学完两年之后,人还是很迷茫,方向感还不是特别强,而在找方向和突破迷茫上面,走过了很多弯路,终于找到点方向。后来才发现,很多这个专业的同学,可能毕业几年之后,依然还找不到方向和定位,东学一点西学一点,很浪费时间,可能醒悟的时候,已经过了3~5年,很难再转回头。

2、为了在工作和学习过得中不断积累和提高学习效率

学习和工作的几年里,几乎每个项目,资料,文档,规范都是有共性的,而由于各个项目的不统一,在接收新项目的,几乎都从零开始,一些非功能性需求的建设已经占去了实际项目的很多时间,投入需求建设的时间其实没多少,最简单的,代码的CURD都是一样,自己在做的时候,针对每个项目都有改进,比如这个项目统一了CURD,那个项目梳理出了公共代码,但是项目是分开的,最终新的项目,也是从零开始或者复制,再加上人工,手工,人肉运维,不断的繁琐而简单的工作的学习中无法脱身,影响进入下一步学习。这类似于温水煮青蛙,没有感觉,可能慢慢拖死自己,特别是做项目的前两年,除了数据的添加删除,还是这些。重复开发,无法共用这些都消耗了很长的时间。比如一直想学大数据,但是由于没有好的平台依托,目前还是无法投入学习。

3、为了可以总结和反思,可以不断的打磨出一个平台,一个产品或者一个精品

这几年的工作和学习中,有很多都是在学习,在努力,也很上进,资料有不计其数,但是却在用的时候,没有深入或者精通某一个模块,最常见的,连自己精通的模块都无法界定,不自信,没有自己的深入心得,比较浮在表面上。自己近乎有两年的状态如此,一直在努力,但是却一直没有达到预期的,别人认可的效果,接触的面好像很多,但是却没有哪一样是完全吃透的。最终发现的原因是没有做好总结和复习,反思,一个知识点以为看过了就懂,但是没有结合实际进行提炼与打磨,没有吃透,就往下一个模块,最终导致好像不断的在捡东西,但最终这些东西都不是自己的。所以需要打磨自己的东西,能谈出自己心得,这就是自己的产品,就是自己的精品,或者自己就一个精品。

4、为了扩大自己的视野和学习心态,开放心态

学习中最怕和就是无沟通与交流,没有他人的指点和自己的固步自封,坐井观天等心态,在学得一些技术之后,开始自以为自,然后偏向于安逸。明显,这种心态自己曾经有过,而且持续很长一段时间。这间接造成不管是沟通、技术方面都慢慢出现问题。自己一直相信,心态有多开放,有多宽容,帮助的人越多,自己也才更好的成长,不管是技术还是管理,包括生活等。

 二、个人需要搭建怎么样的研发平台来学习

1、可以随时随地的学习,只要有网络和电脑,就可以学习

闲碎的时间常常存在,比如学校上机,看手机,还有一些无聊的聚会,甚至上厕所,这些都要能可以用来学习,网络现在无处不在,有个手机就可以上网,所以这些时间要能充分利用起来。

2、可以好的工具和学习环境

学习过程,工具的成熟度和熟练程度很多时间影响到自己的学习效率。比如vim的配置使用,熟练之后,不管在编辑和代码方面,速度都比一般的操作快得多。还有jenkins,在这个工具上不断的学习和积累,不管是配置和权限,发布,运维,分布式都能很大的帮助,同时节省很多时间。

3、可以不断的学习目标,最好从基础程序员到总监

学习有一个从零开始,到不断往上的过程,并且有目标,知道每个目标阶段需要什么样的技术,能力,成长时间等,做到心知肚明,不浪费多余时间 。可以不断的有学习积累,在积累上由量变到质变

5、可以不断的跟外界沟通交流,避免闭门造车,固步自封

需要不断的与外部学习,获取到外部的建议,看到自己的不足,同时也看到自己的优点。在自己不断学习的过程中,同时不断的成果,并让别人看到,给自己提建议,在自己把自己的思路成果对外贡献的同时,别人也一样帮自己提升。

 三、研发平台怎么搭建,搭建到什么样的程度

搭建的思路都是先有一稿,然后再后期慢慢在这一稿上面做好优化,同时参考当前社会主流技术,便于学习。

1、制定整体学习规划和学习路线,技术路线和成长规划

平台构建过程中,产生大量的技术产物和管理产物,而在大量的项目过程中,同时也会产生大量的问题导致过程中细节的不完善,人为的不完善及限制,导致平台无法正常管理和运维,开发平台的管理规划即针对整体平台的运维管理进行的建议,以达到管理统一有序,过程明确,产物明确,目标明确

需求->准备->组织->开发<->内部测试<->用户测试<->自动测试->生产(试运行)->生产->运维整个流程完善,每个流程中又包括多个工作,如需求管理,同时每个工具必然有一定的产物,如需求管理的产物是需求管理基线和需求文档。

序号模块功能产物备注
1需求需求管理管理基线
2需求组织分工需求人员管理表
3需求需求变更
4需求需求确认需求文档
5需求需求分配
6准备工具准备工具管理文档
7准备组织结构人员资源清单
8准备环境准备开发基线/文档管理基线
9准备资源准备
10准备基线准备
11组织人员资源人员资源准备
12组织开发管理
13组织沟通管理
14组织角色分工角色分工及联系沟通表
15组织版本管理
16开发开发培训
17开发开发管理
18开发单元测试
19开发开发流程
20开发部署管理
21开发问题处理
22测试(内部)内部测试
23测试(内部)组织机构
24测试(内部)问题反馈
25测试(内部)Bug管理
26测试(内部)接口测试
27测试(内部)功能测试
28测试(内部)集成测试
29测试(用户)业务测试
30测试(用户)问题反馈
31测试(用户)Bug管理
32测试(用户)问题反馈
33测试(用户)测试报告
34测试(用户)版本管理
35测试(自动)测试配置
36测试(自动)压力测试
37测试(自动)安全扫描
38测试(自动)功能测试测试报告
39测试(自动)安全测试安全报告
40测试(自动)压力测试压力报告
41生产(试运行)切换计划
42生产(试运行)工单管理
43生产(试运行)账号管理
44生产(试运行)安全管理
45生产(正式)运维监控
46生产(正式)工单管理
47生产(正式)日志管理

为达到以上的要求,也为了过程有记录和沉淀,考虑一些必要性的管理工具,暂时考虑以下几个工具:

序号说明技术版本备注
1文档管理GitBook企业内部做好考虑,团队未必每个人都能接受markdown
2Wiki管理GitBook企业内部做好考虑,团队未必每个人都能接受markdown
3开发过程管理Jira
4开发工具管理百度网盘公司内部建议使用FTP或者内部文件系统
5邮件通知163邮箱建议使用企业内部邮箱

以下为文档管理基线示例

2、制定持续集成环境,为学习提供基础的准备和提升效率

持续集成他一套比较成熟的自动化研发解决方案,使用也有几年时间,不同的人有不同的设计,有些可能只是发布工程,这里针对于需求、开发、测试、文档、运维几个维度,进行了整合,同时也制定和管理方案,以达到基础规范 – 组织结构 – 基础架构 – 业务开发 – 持续集成– 自动化部署 – 自动化测试 – 生产运维监控 – 在线升级 几个方向自动化,这里不得不提一下Jenkins+git,确实是整个自动化的核心。目前考虑了一下这些工具,针对于开发的:

序号说明技术版本备注
1代码管理Git(gitee)2.17.1企业内部建议使用gitlab(更能满足需求)
5代码管理客户端SourceTree2.7.6
2自动部署工具Jenkins2.107.1不建议使用太新版本
3私服库Nexus2.14.1不建议使用3.x版本
3构建工具Maven3.6.0
4代码检测Sonar5.x不建议使用太新版本
5镜像管理Harbor1.5.2
6镜像容器Docker1.12.1
7容器管理Kubernetes1.10不建议使用太高版本,跟着社区走

自动化持续集成的效果如下:

文档持续集成效果如下:

3、下载和整理软件工具,整理软件工具版本

基础环境完善及配置,为整个开发平台做基础,以环境搭建为主,为本地开发环境。

使用的阿里云服务器规划如下:

序号作用服务器资源(系统/内存/硬盘)IP规划备注
1开发服务器_masterCentOS7.4_x64_4G_40G192.168.1.110
2开发服务器_slaveCentOS7.4_x64_2G_40G192.168.1.111
3开发服务器_slaveCentOS7.4_x64_1G_40G192.168.1.112

规划的使用工具如下:

序号说明工具IP是否集群文档完善进度备注
1基础环境JDK172.18.11.17单点已完善
8反向代理Nginx172.18.11.17单点已完善
11自动部署工具Jenkins172.18.11.17单点完善中
12私服库Nexus172.18.11.17单点已完善
17链接跟踪skywalking172.18.11.17单点
13代码检测Sonar172.18.11.17单点
2缓存工具Redis172.18.11.17单点已完善
4消息列表Kafka172.18.11.17单点已完善
10分布式注册中心zeekeeper172.18.11.17单点完善中
6分布式注册中心Eurake172.18.11.139单点
10分页式配置中心Apollo172.18.11.139单点
6数据库MySQL172.18.11.139单点已完善
1开发过程管理Jira192.168.1.120集群
3Redis监控工具Redmon192.168.1.119单点
5消息管理工具Kafka-Manager192.168.1.119单点
7数据库主从MyCAT192.168.1.111/112集群
7容器管理Kubernetes192.168.1.1110/111/112集群
9高可用KeepAlived192.168.1.110/111/112集群
14镜像管理Harbor192.168.1.110单点
15自动部署Ansible192.168.1.119单点
16自动部署管理Ansible Tower192.168.1.119单点
17链接跟踪pinpoint192.168.1.119单点
18日志监控elk192.168.1.119集群
19服务器监控Zabbix192.168.1.119单点

工具的保存是放在百度云上面:

4、规划平台非功能性需求组件,包括基础组件等

功能重用,组件重用,目前最好的技术承载就是微服务了,这也是这几年才出现,这样规划研发平台构架,对我而言,微服务架构自然成为不二的选择(后面的中台业务也是在微服务上进行进程创建)

服务设计原则

服务单库设计,以减少迁移,服务之前影响等;
基础服务只为调用设计,位于服务的底层或者中间层,基础服务禁止调用业务服务;
业务服务调用基础服务,或者其它服务,业务服务为服务的顶层,用于定制化业务;
同一级服务之间可以互相调用,只能自下往下调用,平级调用,禁止自下往上调用,以避免服务混乱及维护混乱。
每种服务目录按999个服务规划

服务设计规划

类型目录名称说明备注
教程示例服务做示例工程,包含有所有服务调用示例
前端应用门户服务与中台服务同级,用于统一门户服务
前端应用应用服务前端应用或者手机应用
网关应用网关服务对外网关服务,与平台组件同级,但仅做为网关部分
中台服务中台服务服务于前端应用,处理业务,可以服务之间互相调用,或者调用基础服务
基础服务基础服务公用基础组件,只能被调用或者调用公共或者组件包,不能主动调用其它服务
基础服务公共服务基础公共包,所有工程的基础,包括配置,页面,核心包等
基础服务组件服务基础组件包,用于第三方等,组件包不能单独运行,只能被依赖
运维环境监控服务监控平台,用于运维平台,目前仅规划,有可能与平台服务合并一起
运维环境平台服务包括注册中心,配置中心等

工程目录规划

关于命名方向,一直不知道用什么名字比较合适,所以使用自己网站的域名。

序号目录名称目录规划端口规划权限备注
1公共服务alinesno-cloud-common研发
2组件服务alinesno-cloud-component研发
3平台服务alinesno-cloud-platform24000+研发
4基础服务alinesno-cloud-base25000+研发
5业务服务alinesno-cloud-business26000+开发
6门户服务alinesno-cloud-portal27000+研发
7网关服务alinesno-cloud-gate28000+开发
8应用服务alinesno-cloud-web34000+开发
9监控服务alinesno-cloud-monitor35000+研发
10示例服务alinesno-cloud-demo30000+研发置于guide基线

5、提取出业务中台规划,并完善组件,打磨中台业务产品

上面也提到,业务中台也是在微服务上面构建,设计原则加上了几个点,分别如下:

按“重中台”+”轻应用”设计,业务应用逻辑思路放在前端应用,推荐是尽量减少或不拆分前端服务;
重中台的建设,在于前端应用共性部分的抽取和后期的沉淀,形成中台业务服务;
中台服务调用基础服务,或者其它同级服务,中台服务为服务的中层,用于业务共性(共享)抽取;

整体中台的业务架构如下:

中台业务架构设计

中台业务建设目标如下

中台业务建设目标

6、统一和通用的权限配置系统和界面设计

这个就是通用的,只需要在配置平台添加好菜单,分配好账号权限,本地开发只需要账户就可以进行本地开发,配置平台包括的一些功能规划如下:

应用管理:用于配置系统应用,添加和删除管理。
用户管理:用户是系统操作者,该功能主要完成系统用户配置。
部门管理:配置系统组织机构(公司、部门、小组),树结构展现支持数据权限。
岗位管理:配置系统用户所属担任职务。
菜单管理:配置系统菜单,操作权限,按钮权限标识等。
角色管理:角色菜单权限分配、设置角色按机构进行数据范围权限划分。
字典管理:对系统中经常使用的一些较为固定的数据进行维护。
参数管理:对系统动态配置常用参数。
通知公告:系统通知公告信息发布维护。
操作日志:系统正常操作日志记录和查询;系统异常信息日志记录和查询。
登录日志:系统登录日志记录查询包含登录异常。
在线用户:当前系统中活跃用户状态监控。
定时任务:在线(添加、修改、删除)任务调度包含执行结果日志。
代码生成:前后端代码的生成(java、html、xml、sql)支持CRUD下载 。

然后大概的设计如下:

开发人员的开发流程如下:

7、完善软件组件辅助,包括测试、运维、环境管理

以上组件的搭建过程,如果一个人管理,会产生很多问题,同时延伸出其它方向的建设,其中包括最基础的服务器管理和服务预警方向,安全策略管理,平台整体入口和常用文档,功能,平台组件的质量保证,即运维、机房环境,测试这几块。在建设统一研发平台的同时,也自然包括建设这些内容,大概做了一些建设工作,以下为一些设计的示例。

机房服务器管理系统

机房管理系统,针对云系统和服务部署的管理

平台统一门户管理

其它的建议,如包括人才培养,大数据,人工智能,项目管理,都是在研发平台中慢慢积累和培养的产物,而最终的结果是为了整理出一套完整的企业统一研发平台。

四、总结

以上为目前搭建整体个人整体研发平台的思路和设计,一个优秀的研发人员的工作并非只是编制代码,更多的是自己能做什么,完成什么,有什么价值,能帮别人做什么。

column count of mysql.proc is wrong. expected 20,found 16. the table is probably corruptd.

1558 1547 column count of mysql.proc is wrong. expected 20,found 16. the table is probably corruptd.
在用navicat连接时发生了一个错误:
1558 column count of mysql.proc is wrong.Expected20,found 16.created with mysql 50091,now running 50528.please use mysql_upgrade to fix this error。

其实这个错误如果不是用客户端工具的话是发现不了的,因为我远程控制时操作是没有这个问题的。
查了下说是这个是由于升级后未使用mysql_upgrade升级数据结构或用不同版本进行备份迁移恢复造成的。
用Navicat for mysql会有此错误提示:

解决方法:
最后是通过”mysql_upgrade -uroot -p”

命令解决的。
直接用cmd命令执行这个,然后输入密码就好了。会自动升级mysql里的数据结构。
如:

mysql_upgrade -u root -pjoy

mysql_upgrade -u root -pjoy –datadir=/var/lib/mysql/ –basedir=/usr/