信息化平台架构设计

一、为什么需要信息化平台

• 如果没有信息化建设平台，每次新开发一个系统时，由不同的负责人负责开发就会有不同的开发规范，真可谓是八仙过海各显神通。造成系统与系统之间进行对接十分困难，后期运维及交接困难度加大。
• 如果没有信息化建设平台，每次新开发一个系统时，即使同一个项目负责人，在不同时期也可能采用不同的开源框架。开源框架有好有坏，规范也是天差地别，如果对所用的开源框架了解的不够充分，那将是灾难性。因为系统的bug千奇百怪，就像聊斋志异一样，后期运维的成本也是相当大的，如果项目耦合度高，都有可能出现项目负责人都无法运维的现象。
• 如果没有信息化建设平台，每次新开发一个系统时，都要考虑架构设计，权限验证等问题，开发者在前期都要浪费很多时间在这些问题上，增加了项目延期的风险。
• 如果没有信息化建设平台，每次新开发一个系统时，都要花费很多时间在系统的基础设施层上，如缓存，日志 、邮件、性能监控、文件上传下载等。容易造成各个系统的基础设施层的代码乱七八糟，使开发者晕头转向，增加开发风险，也降低了系统的稳定性。
• 如果没有信息化建设平台，每次新开发一个系统时，可能出现一个用户多个账号，多个密码，用户的体验度也必将很差。

二、信息化平台架构设计图

三、介绍一些在企业中常用并且扮演重要角色的系统

1、统一权限管理系统

　　 如果要想打造企业的信息化建设平台，打造统一权限管理系统，可以说是万里长征的第一步。

　　 对于开发者来讲，如果有这么一个系统，那么我们每个系统都可以采用同一种的权限管控方式。我们开发者在开发系统时，就完全不需要操心权限的问题。所需的工作量仅仅是将公用的jar包或者dll引入到项目中即可，开发者在需要权限验证的地方加上注解（java）或者特性（.Net）或者其他资源标识。

 　　对于系统运维人员来讲，可以在统一权限管理系统中管理每个用户的每个系统的权限。用户注册及用户权限的管理可以交由部门负责人去负责，也可以做一套权限变更申请流程。这样的话，即降低IT运维成本，又可以增加用户体验度。他还有一个显而易见的好处，如果某个人离职了，可以一键清除他在每个系统中的帐号权限，因为他的帐号只有一个！

2、单点登录系统 

 　　单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

　　单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，所有的应用系统都不能再直接访问保护资源，像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术。

1. 单点登录涉及SSO认证中心与多个子系统，子系统与SSO认证中心需要通信（交换令牌、校验令牌及发起注销请求等），子系统中包含SSO的客户端，SSO认证中心是服务端
2. 认证中心与客户端通信可通过 httpClient、web service、rpc、restful api（url是其中一种） 等实现
3. 客户端与服务器端的功能
   1. 客户端：
      1. 拦截子系统未登录用户请求，跳转至sso认证中心
      2. 接收并存储sso认证中心发送的令牌
      3. 与服务器端通信，校验令牌的有效性
      4. 建立局部会话
      5. 拦截用户注销请求，向sso认证中心发送注销请求
      6. 接收sso认证中心发出的注销请求，销毁局部会话
   2. 服务器端：
      1. 验证用户的登录信息
      2. 创建全局会话
      3. 创建授权令牌
      4. 与客户端通信发送令牌
      5. 校验客户端令牌有效性
      6. 系统注册
      7. 接收客户端注销请求，注销所有会话

3、日志系统

　　日志系统对于任何项目都是必不可少的，无论对于测试阶段的debug,性能测试，执行时间，操作记录还是线上的问题排查，访问记录等，日志系统都扮演着重要的角色。

　　日志系统可以手机各个系统生产的日志记录，并且可以在线查看系统日志，特别是错误日志最最重要。当日志系统发现系统中出现错误日志记录时，日志系统将会给开发人员发送报警邮件，并将错误日志详细消息一并抄送给开发运维人员，运维人员也可以打开日志系统查看各种相关日志。小编曾用过使用kibana做的日志系统，给各个业务系统的运行保驾护航，效果那是非常给力的。

4、监控系统

 　　作为开发者活系统运维工作人员，会受到用户的一些反馈信息，比如系统不能使用、某个功能不能使用、查询速度很慢、页面容易卡死等等，如果公司存在监控系统，我们就可以监控服务器的各种新能。其实最常见的监控就是服务心跳，监控服务是否正常运行，服务是否能顺利的连接数据库。

　　我认为一个健全的监控系统应该包含检测各个服务器的CUP、内存、Redis、服务、接口响应时间、Sql语句等等。

　　如果我们有CPU的监控信息，我们就可以实时在线的观测多台服务器的性能，通过检测信息我们也能知道系统卡顿是不是CPU的问题。

　　如果我们有服务、接口响应时间、Sql语句的监控信息，我们就可以准确的判断出是数据库执行sql耗时，还是服务代码写的有问题。因为我们有监控的数据，所以基本上可以很清晰的定位到我们的系统到底哪里除了问题。

　　如果我们有服务心跳的监控信息，当服务响应慢或者服务停止的时候，监控系统就可以及时的监控到，从而可以及时给开发活运维工作人员发送邮件。

5、服务注册中心

 　　服务注册中心，就是将服务的信息注册到该系统上。客户端去服务注册中心寻找服务的具体地址，然后客户端在更具服务的地址去调用具体的服务。

　　虽然说起来很简单，但是他起的作用很大。对于运维来讲，最明显的作用就是我可以随意更换服务地址，假如说A服务器不能用时，我可以将系统的服务地址全部换成B服务器。对于开发者来讲，可以大大的简化代码复杂度，因为我可以将服务与服务相互隔离开，不用相互应用就可以相互调用，从而大大的简化了开发，使服务更加的轻量级。说白点他就是一个RPC框架，或者理解成企业服务总线（ESB）都可以（虽然有点区别）。并且我们开发者可以依托这个系统轻松的实现负载均衡技术，在这里我十分推荐Dubbo + Zookeeper，功能很强大，很齐全。

6、任务调度平台

 　　很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。比如，晚上一点统计前一天的订单或者生产数据，并生产报表，然后在早上7点的时候发送邮件给相关领导。生产数据库与报表数据库同步数据，每晚2点执行。每隔五分钟检查Redis中日志信息，并将其转移到数据库中等等。

　　记得刚毕业那会，想要做一个定时任务，只会在数据库中写job或者使用Windows任务。虽说可以实现任务的定时执行，但是他的局限性很大。比如数据库的job，他只能处理数据库端的资源，并且数据库的资源属于稀缺资源，最好不要占用数据库的资源，但是如果你的服务器很好，数据库也比较空闲，那用job来处理数据也是可以的，但是后期运维会有点痛苦。windows定时任务灵活度不高，我很难在线看到任务的执行情况，我也很难做到任务的动态加载、卸载、隔离等。当我想要做一个多节点集群的任务调度时，是很难做到的。并且如果我有多台服务器都是要做定时任务，那么这些任务时很难管理的，这也会让运维人员非常头疼。

　　quartz是一个非常优秀的任务调度框架，支持Corn表达式，可以方便快捷的利用多台服务器来完成公司内的定时任务的执行，网上也有很多优秀的开源的任务调度系统。

7、报表系统

 　　报表系统虽然占用程序员的工作量并不大，但是他在公司中所起的作用的非常巨大的。作为一家企业的老板、领导层，他们不是很关注系统录入数据方便不方便，列表是否使用了分页技术等等（如果系统做的真的很不好，老板也会很关注的），老板或者管理者需要看到系统中统计出来的数据来帮助他们做出决定来管理企业，企业运行状况老板是很关心的，如果有这么一个报表系统，老板可以很方便的查看到公司各个方面的运营情况，可以帮助老板或者领导及时发现问题。从而在老板的眼中，企业的信息化建设是非常重要的。

8、内容管理系统（知识库）

 　　内容管理系统，主要是将与员工的工作相关的信息记录到系统中，他的工作有哪些，每个工作有哪些步骤，每个步骤如何完成等等，整理成具体的的文档存入系统中。比如一个HR员工，如何从打卡机中拿到员工的打卡记录，这些记录信息应该做哪些数据清洗操作，然后登陆到考情系统中，在哪个位置导入处理后的打卡信息，如何检查导入后的考情信息是否正确等等。

　　如果有这样的系统，企业中员工离职交接问题就会变得很简单了，交接成本也会降低，也不用担心离职员工手里有没有交接的内容，因为所有的内容均记录在系统中。

　　对于开发者的好处是，系统的表结构、接口说明、系统设计文档，系统操作文档等等都可以存入知识库中，方便程序员快速找到相关的文档，迅速解决问题。

9、项目管理系统

 　　之前使用过一套开源的项目管理系统--Redmine，具体业务人员在Redmine上提需求，开发人员更具Redmine上的需求开发功能。并不是说业务人员仅仅在Redmine上提好需求就可以了，还需要开发人员或产品经理去和业务人员好好的沟通，这才能理解需求。这样做的好处是能让提需求的人员重视这个问题，因为没提一次需求，变更一次需求，系统上都是有记录的。自从使用了这个系统，我发现业务员提需求很严谨，不会张口就来，这真的是开发人员的福音啊。

　　有效严谨的需求对我们开发的帮助是很大的，虽然说在开发系统之前，软件开发人员应该比业务员还要了解业务，这样才能更加有效的防止用户该需求。我在刚踏入这一行的时候，有一位前辈和我讲过这么一句话，客户改需求，80%的责任属于我们开发人员，20%属于客户。因为客户不懂软件，而我们是做软件开发的，所以我们应该比业务员更加的了解业务！

　　项目管理系统可以用开源的，也可以自己研发，配合内容管理系统一起使用，对系统的建设更加的有好处。另外，项目管理软件还能有效的量化我们开发工作，指定项目开发计划，保证项目按时上线！

10、文件中心服务系统

 　　文件不好管理----在Web系统中，上传的文件往往放在UPLOAD目录里,然后就没有下文了,后期管理起来只能通过Windows的资源管理器来管理了,这种方式简单的系统应付起来还行，稍微复杂点就有点力不从心了。如果做负载均衡，当前登录人的头像图片就很难管理。

　　不太方便扩展----或者说扩展起来比较费事，比方说做断点续传，秒传，做文件预览，等等。

　　重复工作太多----每次开发一个新系统,上传这块都要全部搞一遍,感觉太费劲,以后还很难再继续升级 只要系统涉及到频繁的文件上传下载可能就都会面临这些个个问题，既然这样，为什么不把这一块单独拎出来开发成一个服务+系统呢。

　　

Web项目开发建议：前后端分离

　　如果一家公司有java团队，又有.Net团队，那么再开发web项目时，最好使用前后端分离技术。java项目最好不要用jsp，也不要用现在非常火的Thymeleaf，虽然SpringBoot推荐开发者使用Thymleaf，但是.Net团队是不会使用Thymeleaf这样的前端框架。同样的.Net也不要使用aspx，更不要使用ASP.NET MVC Razor。

　　其实也并非不能，如果在html中嵌入一个iframe控件，也可以兼容jsp，Thymeleaf，ASP.NET MVC Razor等，只是说最好不要。

　　可以使用传统原生的html + css + js的技术，也可以使用AngularJS、VUE等技术，他们都是非常优秀的前端框架。这样的话，两个团队之间可以相互帮忙写前端页面，或者交由专门写前端的开发人员负责开发。前端开发利器WebStorm，非常好用，没用过的可以体验一下。