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

一、淘宝架构问题

（2007年：500人技术团队；一个WAR包，几百兆字节；业务每隔几个月就翻倍；超过200个功能模块）

1. 团队间协同成本高，业务响应慢[系统上线时间]。（①不同团队多个代码分支，每次功能升级进行分支合并；②jar包冲突，代码不一致；③部分功能开发进度滞后）
2. 应用复杂度高，无法掌控、即失控。典型的架构分层解耦问题！（技术与领域能力、领域能力与业务特性、领域能力之间、业务特性之间，一个人很难清楚的掌握一个业务能力或一个业务特性的细节）[每一次整体打包发布时，蕴含巨大风险；一个小改动，可能带来未知风险；整个应用，牵一发而动全身]

• 2.1、错误难于隔离。典型的架构分层解耦问题！（核心的与非核心的、稳定的与易变的、变化快的与变化慢的、大并发查询与大并发写入更新的 耦合，互相影响，如用户中心服务功能与广告展示功能耦合）[任何一个小问题造成应用实例的崩溃，影响到整个平台]

3. 数据库连接能力很难扩展。（每个应用实例的连接池大小压缩到十个，峰值时间连接数量超过5000个）
4. 系统扩展成本高。（①运行资源要求高，服务器配置高；②无法单独模块进行扩展，只能完整应用一起扩容[按整个应用的资源配置，如CPU、内存、存储]）
   • 一个几百兆字节的WAR到几百个WAR；
   • 用户中心 -- 千岛湖项目:交易中心+类目中心 -- 五彩石项目:商品中心+店铺中心；
   • 两周一次迭代到一周两次迭代（解耦前后不具备可比性？）；
   • 熟悉整个应用的架构和流程到专注自己的领域；
   • 整个应用被拆分为多个服务中心和专门负责前端交互的应用模块；[每个核心服务中心拥有各自独立的数据库]
   • 可支持“细粒度”的精准扩容；
   • 淘宝订单创建请求（点击“立即下单”或“结算”，一次页面对后端服务的调用请求），后端发生200多个服务调用（即响应订单创建请求的服务，内部触发了200多个不同服务的调用）；

二、架构设计思考

• 技术微服务与技术平台[开发平台]、技术平台与领域微服务、领域微服务与业务应用 分层！！！
• 核心的与非核心的、稳定的与易变的&变化快的与变化慢的、大规模查询的与大规模写入更新的 解耦！！！

1. 分层：技术（开发平台与独立的中间件服务分开；公共框架及能力纳入开发平台，如定时任务框架、批量业务框架、事件平台、数据字典组件、系统参数组件等）、领域能力（所有领域微服务都是对等的，不存在公共与非公共的区分）、业务特性；

   • 1.1 开发平台实现以“库”、或“公共服务+库”的形式被复用，如元数据驱动框架的实现、前端统一框架的实现、BPM实现、数据字典的实现！
   • 1.2 开发平台实现以“公共服务+配置”、或“公共服务+配置+应用插件”的形式被复用，如定时任务框架、批量业务框架、事件平台！
   • 1.3 公共服务是独立部署的微服务！

2. 解耦：不同技术组件、不同领域服务（支持商品配置管理与支持商品高并发查询的是2个微服务？）、不同业务应用（大的：不同行业应用、人连接与物连接、2B2C应用；小的：不同角色的应用、不同渠道的应用[客户自助类的，Web应用与微信小程序、MobileApp）；

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