2016-SDCC中国软件开发者大会-笔录

前言

2016-SDCC中国软件开发者大会 于 2016.11.18 - 2016.11.20 三天在 北京京都信苑大酒店 举行。

有幸公司提供机会参加了这次会议。回公司做了总结。

摘抄部分总结至该博客,与大家分享。

特别说明:

下述均从我及公司的角度摘选部分。不包含SDCC所有的内容。

正文

2016-11-18上午-全体大会

专题内容

  • 技术雷达之PaaS容器即进程,PaaS即机器,微服务架构即编程模式(ThoughtWorks)
  • 如何设计高可靠的分布式并行系统(Erlang语言)
  • 新一代华为PaaS平台助力企业IT全云化转型(华为)
  • 提升内容分发效率和价值背后的核心技术(一点资讯)

关键词

  • 微服务、Docker容器、云部署、华为云解决方案、机器学习应用(资讯应用-内容分发效率)

一些有意思的概念

  • 当前系统的复杂度:规模复杂度>逻辑复杂度
  • 部署虚拟化:云作为默认平台,实现部署云迁移。“not build merchine for process”。
  • 增加系统的弹性(比如一个容器节点有问题了,可以直接删除掉、比如促销活动时要临时扩容,可以临时租用容器节点)
  • 部门墙的概念(部门及团队之间协作的痛点集合被定义为‘部门墙’)
    • 通过优化流程,打通部门墙,减少部门、团队合作的成本

评价

  • 主要是强调‘微服务’、‘容器技术’、‘云平台’是未来互联网应用的三个趋势
  • 这部分感觉更多是公司在推销自己的产品,渲染公司产品是符合未来趋势而生的。干货不多
  • 提到了‘蓝绿部署’(不停服发布的部署方案)。可以作为以后‘不停服发布’的考虑方案参考

其它

  • Erlang语言(面向并发的编程语言:函数式、动态类型、脚本语言、运行于虚拟机。)

2016-11-18下午-电商架构专题

专题内容

  • 唯品会电商平台架构治理(唯品会)
  • 京东搜索架构演进之路(京东)
  • 创业型千万级电商萌店架构演进之路(萌店)
  • 智慧医药电商系统的探索和实践(岗岭集团)
  • 传统电商架构的云计算之路(独立技术顾问)
  • 淘宝商品体系架构的历史和演进(淘宝)
  • 国际电商的基础架构及全球区域化部署实践(阿里巴巴)

关键词

  • 微服务、Docker容器、云平台、容灾部署、高可用、元数据

一些有意思的概念

  • 业务的自动化监控(核心服务调用量实时监控、系统运行时相关参数的实时监控、应用错误信息的频次及时间统计、全链路调用链:含SQL)
  • 架构治理的原则和方法
    • 建立专门的治理机构
    • 标准和规范先行
    • 治理前先建立管控流程
    • 以架构为蓝图,问题驱动
    • 先拆分再整合
    • 业务架构、应用架构、数据架构治理紧密结合。以业务架构为核心
  • 元数据统一管理
    • 适合系统的元数据(核心数据)
    • 生产库同步元数据到元数据库(做到准实时)
    • 元数据需要变更,在基于元数据的系统中操作后,经多重审核后,再同步到生产库
  • 公共参考数据管理
  • 系统内的所有数据定义(比如状态枚举、类型枚举等)均统一扎口
  • 数据定义好后,入库‘公共参考数据库’。使用者通过公共参考数据管理平台进行查询和变更。同时会有变更通知服务
  • SQL治理
    • SQL评审通过人工审核成本高,且存在人工误差。因此采用流程优化、工具辅助来管控
    • 方法:
      • 测试环境中在SQL执行前配置SQL
      • Interceptor,拦截到所有执行的SQL。
      • SQL Interceptor将拦截到的SQL,传给SQL Validator。
        • SQL Validator首先对SQL进行语法等规则校验(是否全表查询、更新等)
        • SQL Validator再在生产库执行该SQL(Insert、Update操作不提交)。
      • 上述步骤如果发生异常,自动提SQL bug
  • 利用SpringBoot框架来实现微服务
    • 每个服务足够简单,降低学习和维护成本
    • 可以独立测试和部署
    • 可以独立扩容/缩容
    • 使用新技术变得更加容易
    • 适配团队组织架构
    • API First(API的定义需谨慎)
  • 开发即测试即运维
    • 应用负责人从开发、测试、发布、性能、稳定性端对端负责(当然要提供足够高效的工具来配合实施)
  • 跨区域的多机房部署
    • 实现多地路由表数据一致性
    • 基于路由表实现
    • 接入层做访问路由(就近访问、负载均衡、流量调配)
    • 服务层路由(服务调用的路由:微服务多节点部署的)
    • 消息路由
    • 数据同步(内网专网做到秒级同步)
    • 异地容灾流程及一致性保证
  • 元数据驱动架构(其实就类似我们服务治理搞得产品模板引擎,只是我们的产品配置是开发的时候配的,没有抽象出去)
    • 元数据:描述数据的数据
      • 模型:接口(API)、数据(DO对象)、存储(DB)
      • 逻辑(基本能力):组件化代码片段、脚本片段、规则
      • 流程、配置
    • 分析元数据。利用元数据来实现控制和实现应用的逻辑(业务和技术分离,非技术人员参与开发,配置产品流程)
    • 数据分离:基础数据、控制数据、流程数据
    • 控制逻辑配置和规则抽离。业务执行系统进行组装
  • kubernetes容器化技术(google开源的)
  • 京东搜索架构的演进和思想(不详细讲了。看PPT很容易理解)
    • 提到分级缓存的概念。一层一层的通过缓存拦截访问。用以支撑高并发即系统高可用

一些好玩的内容

  • 有一个电商创业公司刚开始由于招聘困难,招聘人员参差不齐。1.0的系统做成了JAVA、.NET、PHP三种语言构成的系统。(不过经过三年的发展:他们说从16人团队扩展为1500人团队。月流水超过3亿元)

评价

  • 电商架构还是很有内容的。
    • 微服务、容器化在大型电商系统中已经有了较先进的应用
    • 感觉互金系统和电商系统有很多相似点。电商系统的技术发展,值得互金系统参考

2016-11-19上午-全体大会

专题内容

  • 京东双11创新技术和实践(京东)
  • 关系数据库的困境和出路(阿里)
  • 智能驾驶的软件创新之路
  • 如何打造高效、敏捷软件开发平台

一些有意思的概念

  • 京东双11备战
    • 资源规划
      • 识别‘平稳性系统’、‘毛刺型系统’。
      • 指定对应目标,按照目标针对性扩容
    • 夯实基础(功夫做在平时)
      • 稳定的数据中心架构
      • 容器化
      • 高可用中间件
      • 以内存为中心的存储体系
    • 增强智能
      • 订单冷静(分析用户行为,评估撤单概率。依据撤单概率制定订单后置处理的延迟时间。)
      • 订单预测(根据历史交易数据,只能预测,提前备货至对应渠道)
    • 故障模拟演练
      • 定义故障事件集合
      • 0晨(非业务高峰时间)演练
        • 随机抽取上述集合中的1项或几项,制造产线故障。比如:流量调配使某一IDC流量激增;或者把某些服务器宕机;等等
        • 测验运维团队:能否及时发现故障、能否最短时间修复故障
    • 全链路压测
      • 压测Agent设计。
      • 多台压测Agent模拟一定数量并发访问,跑核心业务全流程
      • 系统需要支持虚拟订单、虚拟库存
  • 关系数据库的困境以及阿里OceanBase解决方案
    • 困境
      • 关系数据库应用的门槛高。市面厂商少
      • 造成商业数据库:服务器费用+服务费,是一笔很大的开销,不是所有公司或机构能承受的
      • 扩展性差
      • 主备数据一致性无法强一致
    • OceanBase解决方案
      • PC服务器集群(不用费用高昂的大型机)
      • 服务器之间无共享。副本数据一致
      • 基线数据存储于SSD
      • 每日修改数据增量写入内存
      • 读操作则为SSD基线数据+内存增量修改数据计算后的结果
      • 每日配置某一时间节点,内存增量修改数据写入各个库中

评价

上述所讲的这些实践。确实有点耳目一新

2016-11-19下午-高可用架构专题

专题内容

  • 性能驱动模式推动海量系统健康发展(新浪)
  • RPC框架高可用实践(到家平台)
  • 百度外卖交易系统高可用实践(百度)
  • PhxSQL:高可用、强一致的mysql集群(腾讯)
  • 腾讯云架构设计之道(腾讯)
  • 转转二手交易平台大数据体系化与高可用实践(58)
  • 高可用大数据计算平台如何持续发布和演进(阿里)

关键词

  • 高可用、柔性、全链路压测、大数据监控(实时监控、异步分析)

一些有意思的概念

  • 高可用 != 完美 != 过度设计
    • 架构师要做到‘业务场景’、‘成本’ 与 ‘可用性’、‘完美架构’之间的平衡
    • 架构师要以‘业务场景’作为第一判断要素
  • 优秀的代码是高可用架构的基石
  • 高可用评估体系:SLA
    • 内容:
      • MTBF:故障频率
      • MTTR:恢复效率
    • 通过大数据平台自动化计算SLA值
  • 高可用架构的内容
    • 接入层:流量清洗、流量调度、负载均衡
    • 服务层:异地多活
    • Cache服务高可用。保证Cache命中率,且 Cache服务器节点宕机时,不会造成某一服务器过载
    • 数据库层的高可用
    • 柔性服务的设计
    • 大数据平台
      • 实时追踪:调用链快速查询
      • 风险判断:计算分析可能存在的架构风险
      • 架构展示:通过日志分析架构全景,接口依赖关系,辅助线上业务梳理
      • 业务监控:监控服务访问变化,预判上线项目风险
    • 全链路压测
  • 柔性服务、过载保护一些有意思的设计:
    • 超时透传
      • 比如业务A分为1、2、3三步骤。业务A超时时间定义为10S。业务A在执行时,将业务执行时间一级一级透传给1、2、3。假如在1步骤即耗时8S。那根据评估2,3步骤不可能在2S内完成业务。那么2,3步骤可以拒绝执行
    • 服务分级
      • P0的服务有分钟级别的故障预案
      • P1的服务可以临时用后台操作代替
      • P2的服务可以自动容错
    • 过载保护
      • 过滤无效的流量
      • 拒绝过载的流量
  • PhxSQL
    • 为什么要做PhxSQL
      • 原生MySQL无法同时满足高可用和强一致
      • 主备切换可能发生如下问题:
        • 数据不一致
        • 幻读
        • 调用端分裂
      • Mysql缺少自动选主的机制
    • PhxSQL如何解决MySQL的上述问题,实现数据强一致及自动选主的(这部分见PPT吧)

评价

  • 很多其实是我们系统已经做了的或者正在做的事情。也算是梳理了下
  • 其它一些‘柔性设计’也可作为我们系统未来发展过程中可考虑的内容

2016-11-20架构演进专题

专题内容

  • QQ空间后台架构优化之路(腾讯)
  • 一统三国:阅文集团内容系统架构整合(阅文集团)
  • 互联网金融初创公司从0-1的架构演进之路(我盈互联)
  • 百度万人协同规模代码管理架构演进(百度)
  • 蘑菇街监控系统架构演进(蘑菇街)
  • ContainerOps(华为)
  • 阿里基础运维平台及应用维护平台架构演进(阿里)
  • 三分归一统:移动端开发技术演进之ReactNative崛起(58到家)
  • 同程缓存系统的演进(同程)
  • 链家网大数据平台架构迁移(链家)
  • 京东分布式数据库系统演进之路(京东)

一些有意思的概念

  • QQ空间
    • Feeds(动态)系统的思想
      • QQ空间服务器区域化多机房部署
      • QQ空间写服务
        • 通过路由统一到特定数据中心执行
        • 通过同步中心,异步同步到其它数据中心
          • 划分内容优先级。核心内容做到秒级同步;非高优先级的内容10S同步
      • QQ空间读服务:就近访问
    • 功能优化以实现高可用
      • 动态拉取优化:优化业务规则、实现方式以减少系统性能消耗
      • 流量优化
        • 最优接入
        • 最小流量(压缩数据传输来解决网络瓶颈)
        • 适配服务(比如图片根据访问方式返回不同大小的图片)
      • 柔性可用
        • 容灾调度、或业务暴增时有可能发生系统容量不够。那么柔性就是解决该问题的方法之一。(过载控制也是)
      • 关键点:核心述求、局部放弃、降级服务
      • 柔性实践
        • 服务体验降级:体验降级。降低用户体验,增加系统性能容量(用户体验一定程度是系统性能换来的)
          • 空间动态拉取
            • 关闭预拉取
            • 短时间重复刷新返回304
          • 空间写服务
            • 削量(被动引入的量)
            • 延迟写
            • 合并写
          • 技术侧调优
            • 关闭非关键路径(非核心服务停用)
            • 适当调小超时
            • 合理的重试
          • 数据层cache

评价

  • 上午有内容且有点意思的就上述这个。其它的和我们的不切合
  • 下午的会议没有参加
坚持原创技术分享,您的支持将鼓励我继续创作!