峰回路转的一年，欢笑大于泪水。

2017 年

上半年 1月1日－05月31日（151天）”燃”到”迷失”

下半年 6月1日－12月31日（214天）稳中求胜（业务上），笃定前行（技术上）

  • 01月，国外 clipchat 上线，全栈基于 AWS 云服务
  • 02月，产品运营支持 颗粒噗 ／爱婴斯坦 ／视频转码
  • 03月，狼人杀从分析到开发上线，风一样的配合效率
  • 04月，棋牌类游戏 没想过多参与
  • 05月，离开友加，重定位技术人的何去何从
  • 06月，加入关爱通，起步 DevOps 体系
  • 07月，接手给到网关，这个阶段关爱通技术 团队招聘/面试/培训
  • 08月，给到网关的重生之旅，一波奋战
  • 09月，接手开票系统，与此同时给到进入上线前测试阶段（10月10号上线后，持续迭代）
  • 10月，开票系统经历了 去dubbo、赶业务（进项发票电子化）
  • 11月，启动结算解耦分析，15号发票项目上线（后面一波又一波）
  • 12月，抢时间 商家结算/企业结算/电子发票

某些事情在你回顾的时候，如果无法明确表达出来，说明其本身就充满争议

友加

坦白的讲，离开友加对大家都好。峰回路转是个拐点。（不展开）

关爱通

一个朝气蓬勃的技术团队，充满潜力又暗藏危机。（观察局限于开发体系，对产品及测试体系不评价）

技术

秉承”技术服务于业务”的角度，回顾关爱通这半年所经历的事项，遗落掉的细节也许没办法记录下来，但从基础架构的决策角度也代表了关爱通 Java 团队的技术成长方向。PHP 团队亦步亦稳，在关爱通技术体系中承担着不可承受之重。系统运维也在基础架构团队的带领下，逐渐从幕后走到前台。本文中技术部分罗列问题、解决手段、剩余的问题（待办事项）

6月份刚加入关爱通时，Java 团队已在微服务解耦的道路上，亦步亦稳。当然也存在些问题：

  1. 虽采用 Maven 进行第三方依赖管理，但并没有统一版本控制机制
  2. 虽整合了各种常用工具包，但并未有完善的 review 机制和最佳实践
  3. 微服务的实现标准未统一（既有基于SpringMVC的 rest api 短连接 模式和也有基于 dubbo 的长连接模式）
  4. 微服务的调用标准未统一（既有native式的http调用，也有基于Retrofit封装的调用，还有dubbo的调用)

经过半年的努力，已收到的成效：

  1. 统一版本控制 基于全局 ciicgat-parent
  2. 按能力域整合工具库 ciicgat-sdk
  3. 按业务域整理调用库 ciicgat-api
  4. 微服务实现统一基于 Spring Boot
  5. 微服务调用统一基于 Feign 封装 okhttp
  6. 统一基于 Swagger 暴露开发级 API （其实测试也可以基于此生产接口测试用例）
  7. 统一参数级校验框架（Josh）

与其说还存在的问题不如说基础架构的2018年待办事项

  1. 业务域 API （微服务治理）
    1. 臃肿膨胀 尚未形成合理的机制控制工程师滥用的问题
    2. 鉴权授权机制 （需要从 Frigate 上直接控制）
    3. 调用链分析 （这个可大可小 大的实时追踪 小到普通日志监控）
  2. 分布式调度平台 （gatjob）
    1. 任务调度模型标准未统一(需给出详细的 Job 接入标准 文档级)
    2. 异步任务回写机制
  3. 分布式存储（gfs 内部也称 “高富帅”）
    1. 需要提供脱离于云存储厂商的加密方案实现（高敏感数据）
    2. 内部有无必要规划分布式文件存储系统（GlusterFS/Ceph）
  4. DevOps 平台（本身是个很大的话题，暂不展开）
    1. 批量创建 CI/CD Job
    2. MySQL Client
    3. 资源调度
  5. etc. 兵来将挡 水来土掩

对 2017 年在平台技术部技术上的总结，对个人或团队的总结都可归并为 笃定前行。开发环境和测试环境切换到 k8s , 当作这个团队给出的惊喜。k8s 的下一步上线将意味着团队中有一波人对其进行深入的学习，这是一个持续精进也是一个充满期待的过程。

关于微服务架构的选择上的决策：逐步放弃 dubbo，参考 Spring Cloud 加上特有业务属性构建定制化的微服务实现技术体系。dubbo 也许很好，但不够简单，加上之前社区停滞不前，偶尔还有调优的坑，对团队成员有所要求。我们认为其没有充分的理由说服我们将其放在核心业务的底层技术栈。Spring Cloud 大而全的体系确实可以完全拿来，这种让你使用起来巨舒服的框架实质上会降低技术人员对技术的把控力和敏锐力。站在巨人肩上自建成为了唯一出路，Spring Boot 刚刚好。Spring 群众基础好，即便团队成员水平不一，通过培训可以很快达到步调一致的效果。

尽管业内叫嚣“AI”将取代大部分人的工作，但技术上逐渐被蚕食的领域往往是停留在更底层巨通用的领域。企业即便是被这些技术绑架，但从本质上来讲也不无法对核心竞争力形成威胁。关爱通还不是一家技术公司，但未来在业务高速发展的过程中，沉淀出通用性技术副产品也未尝不可。就目前纯技术角度而言此部分的投入远不够，当然考虑公司盈利又是另一个话题。战略话题放到年总结来讲只能作为来年一个引子。

个人总结：作为技术架构师，在这个团队中需时刻准备技术攻关／选型／编码／解决问题；中高层工程师领导及执行能力的缺失导致架构师需时刻准备一线撸码；运维体系的规划，也是当前阶段技术架构师义不容辞的责任。

业务

关爱通基于 B2B2C 模式，典型场景消费端是员工，其结算端大部分业务则集中在 B 端。隔着一层B去构建C端场景多少需要点本事，这也造就了关爱通大部分业务并不是传统认知的电商业务。

2017年是关爱通业务如火如荼的解耦元年，参考下图

成长的印记

年初会员域、年中安全域启动解耦现已运行在生产环境；权利平台／场景服务／额度／兑换券／给到网关， 为支持业务创新配合业务调整均已上线；第4季度展开资产域、支付域、结算域的解耦现已进入测试阶段，预计18年2月初进入生产；数据分析域（虽称不上大数据，但也在彰显其 BI 价值）；破壁计划，作为一个企业在线订购的体系的横空出世，也标记着B端电商业务体系的架构雏形；开票系统，完成销项发票电子化。

个人总结：业务的解耦过程中，选择适合团队方案跟踪并改进。整个业务解耦分析中存在的问题都有当时的背景，基于当时的场景考虑也许就是那时最适当的方案。解耦要做的第一步是平滑地打破依赖，然后技术及设计升级改造。

团队

平台技术部真正意义上的 Java 工程师不过 20 人。

组织

职能型的的矩阵式组织模型，对产品快速迭代是有影响的。部门间角度及立场的不同导致合作过程中的摩擦在所难免。在这个组织氛围下，按部就班地做好份内的工作就好。

贡献

  • 7 个项目上线（救火2个 主导3个 协助4个 ）
    • 救火2个 ：给到网关、开票系统
    • 协助5个 ：授权码、无线应用发布、产品目录、商家结算、企业结算
  • 驱动技术体系建设（架构团队共同努力的结果）
  • 组内工程师培养（2名已展露头脚，1名心未定，3名亦步亦稳）

最后

2017年，一个字”稳”。不是很满意（有一种力气没完全释放出来的感觉），也还能接受（大方向已基本达成统一）。

2018 年

第八个年头 ，to be a better man .