年终总结

      转眼间 从2015年底到了2017年,回想公司成立时，产品线上从看别人的产品，以及参加教育信息展，再到后来拿竞品，梳理定位自己的产品线，可谓是几次大的变化。

产品线 由最初的设想提供免费的家校互动平台，教学管理系统 ， 多媒体软硬件（典型的多媒体，校园广播等）。再到三通两平台，万物互联互通（典型的集成上海一家公司的产品），留守儿童以及综合素质评价。到现在以创客为核心，人人通，系统集成为业务方向。

 在这做下个人的总结：

刚起步时：在教育信展拿竞品回公司分析，以及通过网上分析相关的产品，分析了很多个公司的产品，通过参考竞品，整理属于公司产品的需求。

需求整理期：秉着粗细粗系统分析的原则，对分析归纳的系统，从用户维度，平台管理层次结构(如：省市区县多级)维度，系统维度,按照系统分析SA，归纳概括了20多个系统。需求通过归纳整理需求目录，需求矩阵，再开会审核，记得当时是三个人,然后每个人分摊需求文档输出的工作。后来招聘一个需求到位后，我们几个抽出来对架构进行设计。

架构设计期：秉着重用原则，一致性原则，基础应用平台化原则 等总体架构设计原则 对系统进行整体架构。

 1 业务架构：秉着粗细粗系统分析的原则，对系统所有的主要业务进行归纳分析，整理各个应用的业务场景，以及关联的业务场景。对应用架构进行铺垫

 2 应用架构：从归纳的字系统分析，理清关键业务场景，并进行归纳整理。从平台用户体系，认证授权，门户进行梳理，分析各个应用的特点，基于领域驱动，以及接口单元化的原则对系统进行服务器层的规划与规定，这个规划对数据架构中做垂直业务拆分，水平拆分有指导性的作用。分析关联的应用，规划关联应用如何的交互，数据流流向分析。输出应用架构到架构文档。

 3 数据架构：经过业务架构和数据架构的分析，基于数据库压力考虑，对业务层面的数据做了垂直切分，在单表查询 并发响应层面暂没明确对哪些业务表进行拆分。在此理清20多个系统，包括用户体系数据，应用教学与用户，统计，用户IM等数据流向做了分析。设计出各应用拆分出的数据库中的表设计。  此时发现需求部门还是以做小项目的思想在做业务需求，理不清整个平台的业务以及应用关联数据流向，没有对整个平台进行分析归纳，把控不到整个平台。比较遗憾此时需求负责人中途撤退。

 4 技术架构：应用层 sping mvc做应用开发 cas实现单点登录，使用shiro做权限控制

   服务层SSM+DUBBOX做为开发框架，dubbo做监控和调度中心提供SOA分布式服务治理，Zookeeper作为注册中心

数据层 Mysql作为数据库(一期做读写分离，托1层或者托两层最后一层可到数据仓库做统计用，2期可用代理或者去中心化集群等)，Kettle做为ETL工具抽取最终数据对接，以及汇集数据到数据仓储供报表引擎做分析用。

  5 分布式文件存储：采用fastDFS做分布式文件系统，采用keeplived+nginx实现HA，vip漂移。

  RabbitMQ做为消息中间件，整个系统为分布式处理系统。

  6 日志分析，采用ELK，运维监控zabix等。

为了应对随着业务系统不断增多，系统之间的调用关系成指数级别上涨，再开发了其他基础组件，会加剧这个问题，我们采用SOA服务治理，通过服务的注册和发现解决系统之间的解耦。

系统之间调用关系太多，如果移动其中一个子系统，可能需要修改与之关联系统的配置文件，重新启动服务，此时会因为更新一个系统，其它系统也需要被动更新，切换很复杂。我们采用引入配置中心

我们规划了很多系统，账户没有统一，每个子系统有各自的账户中心，运营和业务人员需要来回登录才能完成日常工作,以及系统集成。我们采用CAS实现单点登录，以及Oauth2解决外部系统对接存在异构不同库等问题。shiro做权限控制，dubbo来提供登录后权限列表等服务端接口

系统处理能力要求支持<1000TPS，<2000QPS，可支持10W用户同时在线。

由于咋们的互联网系统大概满足28原则，想下应用层够用：

我们不考虑硬负载，采用Ngnix软负载均衡方式。Ngnix通过Keepalived实现高可用。

 此外规划缓存已用redis虽然是单线程，目前够用。

开发期：根据前面的业务分析，以及架构设计，规划出来了，业务-技术点相匹配的人员。由于时间仓促招聘也没按照规划来。整体系统和整体架构只进行过一次培训，显然后期的开发人员没有理解业务和架构方向，没有按照之前的业务和技术架构规划进行。再加上系统需求经常摇摆，少则修改系统业务，多则新加系统，整体应用采用一站式的还是应用商店式的也没慎重考虑，最后采用一站式。

二.2017年计划与展望

项目上：

技术上：

团队上：

个人: