美文网首页面试android app性能优化
企业IT架构笔记3 分层、解耦

企业IT架构笔记3 分层、解耦

作者: 路亚历克斯 | 来源:发表于2018-10-06 17:44 被阅读0次

    一、淘宝架构问题

    (2007年:500人技术团队;一个WAR包,几百兆字节;业务每隔几个月就翻倍;超过200个功能模块)

    1. 团队间协同成本高,业务响应慢[系统上线时间]。(①不同团队多个代码分支,每次功能升级进行分支合并;②jar包冲突,代码不一致;③部分功能开发进度滞后)
    2. 应用复杂度高,无法掌控、即失控。典型的架构分层解耦问题!(技术与领域能力、领域能力与业务特性、领域能力之间、业务特性之间,一个人很难清楚的掌握一个业务能力或一个业务特性的细节)[每一次整体打包发布时,蕴含巨大风险;一个小改动,可能带来未知风险;整个应用,牵一发而动全身]
    • 2.1、错误难于隔离。典型的架构分层解耦问题!(核心的与非核心的、稳定的与易变的、变化快的与变化慢的、大并发查询与大并发写入更新的 耦合,互相影响,如用户中心服务功能与广告展示功能耦合)[任何一个小问题造成应用实例的崩溃,影响到整个平台]
    1. 数据库连接能力很难扩展。(每个应用实例的连接池大小压缩到十个,峰值时间连接数量超过5000个)
    2. 系统扩展成本高。(①运行资源要求高,服务器配置高;②无法单独模块进行扩展,只能完整应用一起扩容[按整个应用的资源配置,如CPU、内存、存储])
      • 一个几百兆字节的WAR到几百个WAR;
      • 用户中心 -- 千岛湖项目:交易中心+类目中心 -- 五彩石项目:商品中心+店铺中心;
      • 两周一次迭代到一周两次迭代(解耦前后不具备可比性?);
      • 熟悉整个应用的架构和流程到专注自己的领域;
      • 整个应用被拆分为多个服务中心和专门负责前端交互的应用模块;[每个核心服务中心拥有各自独立的数据库]
      • 可支持“细粒度”的精准扩容;
      • 淘宝订单创建请求(点击“立即下单”或“结算”,一次页面对后端服务的调用请求),后端发生200多个服务调用(即响应订单创建请求的服务,内部触发了200多个不同服务的调用);

    二、架构设计思考

    • 技术微服务与技术平台[开发平台]、技术平台与领域微服务领域微服务与业务应用 分层!!!
    • 核心的与非核心的稳定的与易变的&变化快的与变化慢的大规模查询的与大规模写入更新的 解耦!!!
    1. 分层技术(开发平台与独立的中间件服务分开;公共框架及能力纳入开发平台,如定时任务框架、批量业务框架、事件平台、数据字典组件、系统参数组件等)、领域能力(所有领域微服务都是对等的,不存在公共与非公共的区分)、业务特性

      • 1.1 开发平台实现以“”、或“公共服务+库”的形式被复用,如元数据驱动框架的实现、前端统一框架的实现、BPM实现、数据字典的实现!
      • 1.2 开发平台实现以“公共服务+配置”、或“公共服务+配置+应用插件”的形式被复用,如定时任务框架、批量业务框架、事件平台!
      • 1.3 公共服务是独立部署的微服务!
    2. 解耦不同技术组件不同领域服务(支持商品配置管理与支持商品高并发查询的是2个微服务?)、不同业务应用大的:不同行业应用、人连接与物连接、2B2C应用;小的:不同角色的应用、不同渠道的应用[客户自助类的,Web应用与微信小程序、MobileApp);

      • 阿里国际业务与国内业务、2C业务与2B业务(淘宝、天猫、1688)、零售与团购(淘宝与聚划算)等。

    相关文章

      网友评论

        本文标题:企业IT架构笔记3 分层、解耦

        本文链接:https://www.haomeiwen.com/subject/fhbhaftx.html