从阿里中台发展史看IT架构转型1——SOA与ESB

1、阿里共享业务事业部发展史

先简而言之，提纲接领说下结论：

• 阿里的淘宝、天猫、1688等等业务扩张是IT架构演进的根本动力。
• 共享业务事业部能否存在，中台能否立起来，技术能力不是核心。核心是组织/业务架构和绩效考评方式，阿里中台也是因把握了“聚划算”这一流量入口抓手，才把与电商部门不平等的话语权拉回平衡点。
• 持续需求->产品不断迭代，才凸显了统一中台的重要性，否则各部门各干个系统免不了。项目制的系统建设轻视运维，较难持续运维迭代系统。

• “大中台、小前台”的组织机制、业务机制建立起来，让“大象也能跳舞”，有效减轻大公司病（决策审批可能慢，但执行层面效果提高了——公共与通用资源已建好，只需在前台面向新方向做业务尝试，一旦领导拍板就能重兵跟上）。

IT技术架构演进

也直接说我的理解和认识吧

• IT架构演进根本力量还是业务驱动，顺带着硬件、OS平台厂商的升级推动。
• 小公司租用SaaS或建私有云SaaS是趋势，集团类公司建中台是趋势。
• 烟囱式系统：各个业务线、部门有需求，领导批，就开建。主要针对本部门的需求，比如OA（流程审批、公文）、ERP | CRM（采购、报销、合同、客户）、HR（人员、考勤、薪酬福利）、项目管理等等，最多调研下相关部门需求。
  • 用户、日志、部门权限及部分业务功能不能复用，造成重复工作，操作员要多处维护
  • 系统间如需交互整合，不同厂商不同数据标准
  • 阿里的各条业务线基础需求更近似（类似集团公司的几个区域子公司），整合的需求更明显
  • 项目制系统建设，容易让各系统中实现的业务得不到沉淀和持续运营
• 分布式架构：
  • 数据共享、业务协同是需求
  • 运维需求：2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是个几百兆的war，大小功能200个。
  • 原各业务系统的能力不只局限在本系统内，化作服务下沉到业务/数据中台层（注册到ESB上），为更多业务应用提供支撑。
  • 信息技术部门“懂业务”不是从IT建设、系统架构层面讲。而是站在组织业务发展角度看问题：业务流程如何进一步优化能更好的提升业务，现有业务能运用什么更好的技术体系来支撑？
• 共享式架构：
  • https://blog.csdn.net/u014231523/article/details/86764420
  • https://blog.csdn.net/u014231523/article/details/86768731

SOA与ESB

星型结构是网状结构的前身。SOA思维和ESB是不同层次的东西，ESB是SOA的一种实现方式，也是一种通用产品。

SOA

1. 松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
   1. 服务的组装
   2. 服务注册和自动发现
   3. 以服务契约方式定义服务交互方式
2. 核心价值是沉淀的这些服务，而不是应用层面实现多个系统间的集成。
3. 统一的核心服务能提供更稳定和高效，同时让前端业务的信息和数据回流到中台。
4. 互联网业务面向最大量的用户，所以系统架构设计必须解决系统扩展性，网状结构更符合需求。

ESB

1. 核心解决的是异构系统间的交互
2. “中心化”的星型结构，中等体量的业务是没问题的。中心化比“点对点”的优势，屏蔽了服务提供者服务接口变化造成的每个消费者都需要调整，现在只需在ESB上进行一次调整。
3. ESB提供了各种技术接口（HTTP、Socket、JDBC、JMS、REST、OGC...）的适配接入、数据格式转换、数据裁剪、服务请求路由等功能。