猿急送>

杭州Java兼职程序员

ID：325478

静守～呐片嗨

java后端架构师

公司信息：
杭州白秋洁网络科技公司

工作经验：
8年

兼职日薪：
600元/8小时

兼职时间：
下班后
周六
周日

所在区域：
杭州
滨江

技术能力

基础扎实，熟悉常用设计模式并用于编码，有代码洁癖
熟悉多线程编程，有较高并发实践经验
熟悉SpringCloud, SpringBoot，MyBatis，Nacos等开源框架技术并对其源码有一定了解
熟悉Linux常用命令，熟练使用docker，熟悉基于k8s, docker，jenkins，maven或gradle 快速搭建微服务项目及自动化部署
熟悉Redis，rocketMq，rabbitmq, kafka，es等中间件
熟悉mysql,Postgresql数据库，常用sql优化及seta分布式事务框架，了解分库分表
了解jvm相关知识，能根据项目生产实际情况进行调优，能使用arthas，jvm相关工具诊断项目常见问题
了解ddd等领域模型思想，并将其用于项目模块划分及编码
掌握js，vue，ezui等前端技术，能完成常规的前端页面开发
掌握python语言，有大数据和深度学习经验
了解网络安全相关知识，注重应用安全

项目经验

### 工保网保险中台
该项目为进入公司后参与设计，开发，从零到一的项目，作为公司保险核心系统，在揽括b端（自然客户）业务的同时处理g端（政府端）的投保业务，供其他项目组接入。

项目架构
- 基于SpringCloudAlibaba微服务架构
- 服务间注册中心及配置中心：nacos
- 网关：gateway
- 服务间通信：feign，ribbon负载均衡，rabbitmq消息队列
- 服务熔断降级：hystrix
- 数据库: mysql；分布式事务：seta；orm框架:mybatis-plus
- 缓存管理：redis，分布式锁：redisson组件
- 日志存储：阿里云sls，es
- 文件存储：阿里云oss
- 链路追踪：sleuth
- 函数引擎：阿里云serverless/FC
- 服务运维部署：gradle，jenkins，docker，k8s

服务拆分
- 产品服务：负责多险种，多保司的产品维护及展示
- 保险服务：该模块为投保业务核心模块，在处理多种投保业务的同时，衔接其他子系统完成投保订单整个生命周期流转
- 保险对接服务：负责与多家保险公司进行业务对接，包含推送，承保，退保等业务
- 订单服务：管理投保订单的支付环节
- 渠道服务：维护其他项目组接入平台的业务
- 风控服务：管理风控相关业务
- 客户服务：维护客户关系及保险经纪人信息（crm）
- 用户服务：用户信息管理
- 数据服务：维护一些数据统计和展示功能

负责业务
- 参与整个服务设计，划分，负责内容涉及多个模块，核心负责保险服务
- 项目初期因组内架构师临时有事休假一月，在这期间代理负责各项业务需求的沟通安排，项目主要模块的基础编码，帮忙解决组内同学遇到的问题
- 项目稳定以后主要负责日常业务迭代，项目优化，线上疑症排查，通用的组件编写

### 白秋洁电商
该项目在进入公司时已上线运作，为社交电商类型项目，兼具移动端，h5，小程序
- 初始架构
- 基于SpringCloud微服务，注册中心使用Eureka
- 数据库使用Postgresql
- 缓存管理使用本地内存
- 服务划分：shopping- mall(核心下单业务)，batch(定时任务)，auth(用户及权限管理) ，eureka(注册中心）

负责业务
- 初期负责解决项目卡顿问题

进入公司后，发现每晚8点左右(商品上新)，公司群里总会出现‘业务人员:平台又卡了’及相关用户截图(app首页或商详页一直加载不出来)，‘老板@业务负责人xx:又卡了，快看看怎么回事?’ 此类对系统问题的抱怨及不满。从周围同事了解到，这种情况已持续了数月，流失了不少用户不说，所有人每天下班后都过得提心吊胆，每打开微信可能就是看到来自业务部门或者老板的抱怨，刚入公司两天的我深深体会到其中的痛苦，而项目初始架构为兼职且已经离职，老板安排我带头进行优化，优化的过称大致如下

* 找到系统瓶颈
* 线上有多台服务器，配置相当高，物理核数多达32c，内存多达128g，核心业务后台部署40 多台，观察网站高峰期，服务器负载并不高，内存有富余，cpu负荷也不高，机房带宽也够，据此排除环境因素
* 通过监控jvm及观察gc日志，发现内存使用和gc工作良好
* 通过监控高峰期核心接口耗时及慢sql打印，发现期间有大量查询耗时超过20s甚至数分钟，同时部署数据库的服务器io飙升

通过排查发现数据库是一个耗时点，此时将数据库进行扩容，分库分表也许是最直接有效的方法，但当时已经做了读写分离以及表分区，再次扩容存在一定复杂性和运维风险，分库分表设计业务改造，成本太大，老板不能接受，只能尝试从其他方面入手，首先看看能不能从外部减少打到数据库的请求

* 落实优化
* 在app抓包过称中发现每次访问app首页调用达十多个接口，商详页也如此，而每个接口里都返回了较少数据，太多请求会导致用户页面加载缓慢，浪费带宽，徒增tomcat压力，于是和移动端同事商量，在业务合理划分的情况下对接口作了改造合并，最终接口减少为3到4个，观察到防火墙上统计的qps明显降低，服务器的负载也有下降
* 减少了外部请求后，开始关注到缓存模块，项目原本使用了本地缓存，包括一些商品，用户的信息都存入了机器内存，且没有根据用户标识或商品标识作命中优化，此外从技术同事和产品经理那了解到，业务高峰期除了卡顿外还经常出现如商品销量数据上下乱跳问题，考虑到新增命中优化或