面向过程 -> 面向对象

早期代码都是面向过程编程，多个业务近似的逻辑代码无法实现继承、封装困难

导致开发工作量巨大，维护性指数级增长

面向对象随之而来，增强了代码编写的可维护性、减少了大量开发时间成本

面向对象引入了许多新的概念，类、封装、多态、继承等

面向对象 -> 包/模块

随着业务线的增多、业务模块的迁移，面向对象的弊端也开始展现

对象间的依赖开始加深，导致对象无法实现单个对象的拷贝

产生拷贝的代码，若存在系统性的逻辑问题（BUG），因为复制粘贴，修复难度递增

故而衍生出，包/模块的管理工具，将整体逻辑服务能力，整合至 拓展包

包解决了 多个模块间的依赖管理、代码版本管理、整体迁移能力等多个问题

包/模块 -> 服务

包/模块，解决了工具属性的拓展包（框架）管理

但若业务层级的包/模块，也采用此方式的话，存在包变更频繁

每一次业务的调整，都需要各个依赖此业务的项目进行包的升级变更

进而 业务层级的模块，慢慢演变为 SOA 服务，通过远程调用的释放开发人员的负担

业务层级的模块，可以随时根据业务情况进行优化调整，而调用方无需关心 服务方的实现方式

此场景，与平时调用第三方 API 类似，都属于远端调用

第三方 API 可以释放开发人员大量的时间成本

服务 -> 微服务

随着 SOA 服务概念的兴起，普通的API服务也开始面临更多的挑战

服务的扩容成本高昂（一个服务项目占用大量内存、CPU、存储空间）

而往往扩容的需求，仅仅来源于几个处理逻辑

微服务的概念由此衍生，将大而全的服务细分，由多个微服务组成整体服务能力

微服务间通过特有的通讯方式（RPC）进行调用

从而避免了服务集群的一荣俱荣、一损俱损

由于使用了同一个内存环境、机器环境、公共逻辑代码，往往一个内容的崩溃导致整体服务的不可用

双十一时期：

• 订单业务大幅增长 - 确保抢购流程
• 支付业务大幅增长 - 确保支付流程
• 资金流水查询延迟 - 让渡服务能力
• 农场、植树临时关闭 - 让渡服务能力

订单互通：

天猫、飞猪、淘宝、1688 … 各种淘系软件内的交易订单均可互通
构建订单中台，统一处理订单逻辑能力、及支付逻辑
做整体中台数据分析，实时统计订单销售总量、各平台总量
所有新增内容中，无需进行支付系统的对接，仅需跟订单系统做简单对接

为何选择微服务

业务驱动、业务增长

业务线快速拓展，出现更多重叠性的业务内容

早期重叠性业务内容解决主要依托多业务线数据库互相调用

由于互相依赖对方的数据库，但业务线又存在调整数据库结构的情况

单业务线调整时，容易影响到其他业务线，产生了更多的开发成本

业务核心聚合

随着业务线的发展，越来越多的重叠性业务展现

将核心重叠业务提炼、单独管理，成为基础服务能力，也迫在眉睫

通过微服务等概念驱动，逐渐剥离出中台相关服务能力

例如：产品服务、订单服务

订单自行与第三方支付平台进行对接，业务组仅需要接入订单系统即可完成整体能力