1、为公司选择快速开发的业务平台，最终敲定Jeesite 2、搭建Dubbo服务项目框架，把业务放在Dubbo，jeesite作为纯展示web 3、改造Jeesite为分布式应用，把内置的组织架构抽取成服务，与集成单点登录CAS，文件存储替换为fastdfs 4、搭建并维护jenkins持续集成平台 5、搭建系统架构环境：   服务器数量：20   前端7层负载均衡：nginx 2台，用keepalived做高可用   前端4层负载均衡：haproxy 2台，用keepalived做高可用   文件系统服务器：fastdfs 2台 前端nginx转发文件请求到该2个节点   缓存服务器：redis  2台 主从复制，缓存数据小暂时不做分片   应用服务器：tomcat应用 与Dubbo服务     3台       调度服务器：activemq，LTS （分布式调度服务） ，zookeeper   3台   数据库服务器：     数量：3台        MySQL 主库2个互为主从，从库1个，使用mysql-mmm保证主库高可用，对外提供vip访问唯一的主库（本来想使用drbd hearbeat 对主库高可用，但是会浪费一个节点，所以综合考虑使用了mysql-mmm）       MyCat 数据库中间件 3个节点，对销售数据与日志数据做了分库分表操作，前端haproxy做转发到这3个节点   监控服务器：nagios  1台   批量管理服务器：salt stack 1台   备份服务器：1台 6、按照上述环境，带领开发团队完成了3个富安娜内部需求的业务系统：     富安娜*管理平台：         利用*开放平台可批量管理多个公众号，开发了*用户、素材、自动回复、参数二维码、*菜单、卡券、和一些营销模块的功能     富安娜发票管理平台：         管理富安娜全国子公司与电商店铺的税号、开票记录，与第三方的电子发票系统实现了线上开具电子发票功能      富安娜vip管理平台：          针对全国直营门店会员的营销系统，完成了 线下会员档案、储值卡、会员图形报表

我来推是一款为机构合作方导流的APP，通过将我来贷线上的流量导流给线下的放款机构， 具体操作为：用户在APP或者H5上申请贷款后，跑批我来贷Wedefend系统，对于跑批通过的业务， 系统前端会展示系统通过，合作方操作人员登录系统后，与客户进行联系，通知客户到合作方网点面签，面签通过后，即可操作放款。 负责模块： APP后台接口 用户认证安全模块：开发统一用户认证oauth2服务， 并在openrestry上编写lua脚本，在用户请求前进行拦截， 对用户token与防重复提交进行校验 动态资料模块：根据不同的合作方，用户需要填写不同的资料，开发了动态表单模块

线下线上一体化，把线下ERP数据同步到中台，在中台承接多渠道业务，已承接的渠道有：*、京东到家、自建商城、饿了么、美团 个人工作内容： 一、线下商品模块数据同步到中台，包含：商品分类、商品品牌、商品档案、商品多规格档案、门店商品经营范围 业务关键点： 1）、数据上报接口性能问题：线下的数据是通过http的方式传递的， 且只会传递一次，中台必须保证数据不能丢失，且快速处理，不能阻塞客户端的业务，所以接口不能做任何业务处理，需要把数据放置到一个消息队列做异步处理，公司的消息队列用的是RabbitMQ，为了保证最大的吞吐量，使用了RabbitMQ确认模式，消息发送后，无需等待，使用异步确认的回调函数，对那些发送失败消息，做持久化存储，开启一个定时任务重新发送消息到队列中，保证消息的正确发送，因为线下数据量巨大，所有消息挤压在一个队列，会使得某一个RabbitMQ实例消息积压导致瘫痪，对每一类的队列进行扩容，例如商品分类队列，会创建50个队列。这样数据就会平均分散在每一个rabbitMQ实例上，类似于kafka的partition（分区）思想 2）、数据依赖性问题： 数据存在依赖性问题， 客户端上报数据可能先上报商品档案、后上报商品分类、商品品牌， 会导致商品档案入库失败， 所以我们会对每一类的业务数据新建一张业务缓冲表，在执行业务逻辑前，会将数据持久化到业务缓冲表中，然后再执行业务入库， 无论入库成功还是失败， 都会回写到业务缓冲表。 我们会有多个业务补偿的策略去重试业务缓冲表的数据，例如：定时重试失败的数据、触发式重试（分类数据入库成功后，会过滤指定分类的商品档案失败数据进行重试） 3）、业务缓冲表数据清洗、按照策略定期删除缓冲表的数据，并把删除数据进行解压写入到OSS中做备份 4）、业务消费，重点关注的是写入的性能，所有写操作都是无事务的批量操作，在一些需要串行写入多表的场景，可能会出现宕机、应用崩溃、内存泄漏等原因，导致数据不一致的问题， 这类问题会通过定时重试业务缓冲表去做补偿 5）、队列的管理，一般的队列创建都是通过配置文件形式在运行时调用rabbitMQ的api去声明队列，但是因为对每个队列做了50倍的扩容，在配置文件维护会显得有点笨重，所以通过代码的形式，动态生成队列、 通过BeanFactoryPostProcessor 在IOC容器注册BeanDefinition 实现程序动态生成多个队列与监听器 二、分库分表，使用客户端分片架构，接入sharding-jdbc、基于sharding-scaling sharding-proxy不停服全量和增量数据平滑迁移到扩容库，这是个人原创的迁移示例博客地址： https://blog.csdn.net/beichen8641/article/details/106924189 三、生产问题排查及解决，排查执行速度慢、内存泄漏、死锁、CPU占用率过高等问题 四、代码审查 五、版本需求迭代