项目简介： 中国银联唯一业务子公司，金融供应链大平台，业务范围极广，分为物流、专业批发市场、总部型经济三大主营业务，都涉及到底层POS机、银联一次二次清分，邮政EMS、云仓储等上下游供应商衔接业务。实现三流合一：资金流、信息流、物流一体化综合服务。平台有大量合作企业对接分流。 运行环境：CentOS7、OpenStack、Tomcat8、JDK1.7、nginx 开发工具：Axure、Xmind、Idea、Git、Maven 、Svn、PowerDesigner12.5、Architect 7.5.4 开发技术： 1．后台Springmvc、Mybatis、Netty、Zookeeper + Dubbox定制化构建面向服务的应用架构 2．前端 定制化Angular、JS、CSS3、Html5等 3．中间件：RabbitMQ集群、redis集群、Erlang统一session管理、独立工作流+状态机、分布 式文件系统、独立定时任务分发器、专业负载均衡服务器、加密机、IM系统、独立清分系统、 POS机路由调用系统等 4．技术架构：分布式大型系统架构，云平台支撑，大数据支撑、大数据分析等。 5．数据库：日本电信技术XPosgreSql分布式主主从20个实时节点同步。 6．服务器监控：小米监控 职责描述： 战略规划、产品路线、产品设计、需求分析、详细设计、数据库设计、核心开发、技术研究、更和缺陷修改等。 主要工作： 本人负责三大部门之一--总部型经济的团队管理、产品设计（重塑）、技术研发（重塑），从零到一的过程，入职前三个月都只是熟悉公司整个庞大的技术架构体系、服务器架构体系、产品架构体系。总部型经济产品供应链（含资金清分），以及虚拟账户体系（含资金清分）+统一支付系统，从需求调研、产品设计、产品规划、用例图、原型图、指导管理技术经理以及前后台技术的开发工作，全面掌握公司架构和业务，技术难点、瓶颈攻关，面试、培养&带领新人，技术把关、技术培训，以及面对客户等。 项目难点： 1.中心化系统三高： 1）DNS缓存+CDN负载均衡；LVS+keepalived高可用群集实现双机热备，由多台路由器组成一 个热备组，通过共用的虚拟IP地址对外提供服务，每个热备组内同一时刻只有一台主路由器提供服务，其 他路由器处于冗余状态，若当前在线的路由器失效，则其他路由器会根据设置的优先级自动接替虚拟IP地 址，继续提供服务； 2）多实例Tomcat横向扩充+多层nginx负载均衡； 3）另外针对复杂业务可以DDD结合运用OPM对象过程建模，一般用于军事和火箭等高科技工程设计中，利用 星型模型、聚合模型，大体设计思路为主表状态要单独抽出来建表，详细描述一下OPM：明细表是事件明细， 主表是当前状态（截止至今为止的快照），明细表是造成主表状态变动的原因，明细表可以回溯重播，计 算出当前主表的状态，也就是说事件导致状态变化；注册中心ZK三台以上奇数横向扩充； 2．中心化系统分布式事务处理：事务补偿机制（两阶段提交：可靠消息+协调程序+定时任务+redis缓存）

项目简介： 本项目由互联网大厂出身的研发人员设计开发，是美的官网电商平台阉割而来，美的官网电商平台当时双十一成交额100多亿，需要开发的新需求还是较多，在品牌日全国500卖场新场景下还有部分优化余地，该场景本来就是大部分排队柜台收款，并发数要求不是很高，上线运行两天时间也出现过卡顿现象，也可能是美的云并不十分稳定，其它应用系统抢占了资源，没有做资源隔离。 运行环境：美的云和阿里云、CentOS7、OpenStack 、Tomcat、Mysql、JDK1.8、Tengine 开发工具：Idea、DataGrip、Git、Maven、Svn、PostMan、Jmeter、PowerDesigner12.5、StartTeam2005。 开发技术： 1.后台SOA服务：Springmvc、Mybatis、Groovy、Zookeeper+Dubbo、CXF、Hessian、Netty 2.前端Angular、Jquery1.X、Ajax、CSS3等。 3.前后端分离架构，支持异步和并行； 4.中间件：Rocketmq、Redis、EasySchedule、Netflix Hystrix 5.分布式营销电商，模块划分（CCRM/cmcard/cmms/cmms-weixin/cmo2o/cmsms/marketing-system-v2/airO2O） 6.单点登录、线程池+阻塞队列、分布式集群/Mysql主从/Redis集群等，JUnit4做单元测试。 职责描述： 业务迭代开发、系统优化（本部门人少，后期靠其他部门技术实力强的团队支援） 主要工作： 1.新需求分析、详细设计、接口定义、分配任务、最后文档补充完整； 2.编码实现：二维码开发、统计报表开发、代码性能优化、压测和调优、服务器参数优化。 项目难点： 技术方案几个亮点： 1.分布式锁：setnx+过期时间一条完整命令，加同步锁，判断可能网络异常情况对锁失效的处理。 2.事务补偿机制：远程调用异常或超时异常，本地重试5次回滚远程服务脏数据； 3.采用框架限制策略大量使用匿名内部类控制代码表现形式，看起来凹凸有致，非常优美，而每 个匿名内部类只允许使用一次，不会有线程安全问题。 4.运用ArrayBlockingQueue来处理高并发，强制每个请求排队访问数据库，基本上避免了乐观 锁的使用，其次是可被CPU二级高速缓存加载，处理速度很快，实际上不弱于 LinkedBlockingQueue（实际很多业务场景性能并不太出色，还有内存溢出的风险）。 5.定制化开发分布式一致性Paxos算法统一分发ID，以及PageHelper高并发定制； 6.购物车每个用户有9个，每个购物车最多可买12件商品，好处是多实例时购物车实例可在多 台服务器上，每个用户所有购物车都放入Redis缓存，最后计算购物车总数时从缓存进行用户 购物车数据累加计算。 7.报表Redis缓存实现定时任务刷新页面数据：倒计时5秒清空缓存并刷新页面； 8.新增数据：先保存数据库，再放入缓存；更新/删除数据：先更新/删除数据库，再删除缓存

项目简介： 华医康道互联网医院解决方案，基于移动智能终端与医院信息系统实时连接，将线上复诊、诊间支付、出院随访、健康档案、医院宣传、健康宣教等服务整合延伸到*，打造医院+互联网的专属平台，实现医院、医生与患者之间的互联互通，减轻实体医院门诊压力，减少患者就医奔波，让诊疗变得简单。 华医康道医联体解决方案基于医联体信息平台，实现资源整合、业务协同、患者分流，让"远医"解"近疾"，让患者在家门口就能看好病，是区域互联网医院的变体版本。 微前端：pc端/移动端（小程序、公众号、APP【*/平板/机顶盒】）/第三方应用； 业务&数据中台：预约挂号中心、门诊中心、住院中心、订单中心、物流配送中心、处方流转中心、签章认证中心、上链（超级链/国金公链）中心、用户管理中心、支付中心、远程问诊中心、远程会诊中心、检查检验报告查询中心、住院清单中心、健康档案管理中心、药品目录中心、评价中心、互联网医院监管平台、家医签约平台、医患随访平台、智能导诊服务、健康宣教服务、养老中心（社卫、日照、居家，手环/睡眠设备数据中心）、微服务、数据中心（HIS管理中心、数据采集、数据建模、数据加工、数据应用、数据资产管理）、消息通知系统、医院前置机HIS服务系统、HIS系统（医生工作站、排号器）； 技术中台：Jboot全家桶微服务开发框架、服务治理； 混合云平台：容器、资源（集群化MQ、数据库、缓存等）、网络 运行环境：CentOS、vmware workstation、Docker、Tomcat、Mysql、JDK1.8 开发工具：Idea、DataGrip 、Svn、Git、Maven、Nexus、Gitlab、Jenkins，项目管理工具：禅道、PostMan、Jmeter、 PowerDesigner12.5、StartTeam2005、OmniGraffle。 开发技术： 1.后台Jboot全家桶微服务架构、dubbo、redis、Elastic、MongoDB；SpringBoot2.x+mybatis-plus等 2.前端Vue饿了吗架构，前后端分离 职责描述： 架构设计、核心模块编写、优化迭代、研发管理、中台改造、PaaS建设 主要工作： 任务划分排期、绩效考评、技术预研、技术方案设计、架构设计与优化、核心功能优化、版本迭代、中台改造、 保证项目/事项正常推进（紧盯关键任务里程碑，管理好主要干系人，预判风险，协调资源解决关键问题等）； 合理频次的一对一沟通（比如1个月至少和每个人开展1~2次1对1沟通）；挖掘/规划新的、有价值的业务方向； 团队集体学习、提升；流程制度优化；业务/技术培训会议（推动个人学习成长）。 项目难点： 1. 高并发处理： 1）主要流程同步执行，次要流程异步执行，次要流程较多的则拆分到单独的模块去异步执行或使用消息队列，彻底和核心流程解耦，提高核心流程的稳定性以及降低响应时间； 2）一段逻辑调用了多个dubbo接口，而这些接口之间并没有数据依赖，则可并行调用，降低响应时间； 3）时间换空间策略：采用HTTP的gzip压缩算法网络传输数据；对APP的请求接口进行分类，使用版本号判断哪些数据更新，只下载更新的数据，使用更多的代码逻辑处理更细粒度的数据； 4）空间换时间策略：缓存复用计算结果，降低时间开销，CPU时间较内存容量更加昂贵； 5）统计大数据量字段：采用增量式算法，只计算增量数据和之前计算结果合并，在字典表新增统计字段，定时任务查询增量数据，对要查询的时间字段加索引，采用大于某个时间点的方法，使索引生效，原理是数据库查询全表数据量大于30%，索引则失效； 2．支付中台数据库架构： 首先排除两种方案： 1）主从、主主架构；因为复制同步有时差，即使是内网服务器也可能出现网络问题，只有主备可行 2）sharding-jdbc分库分表；因为分区键(partition key)只允许选择一个，业务SQL限制太大，即使是通过映射法或基因法来解决，或者大众点评做的多维度分库分表方案（成本高），但都过于复杂。 解决方案：分库分表下沉到DB，最优方案是代码层不做分库分表，NewSQL，如：TiDB