微服务（或称微服务架构）是一种云原生架构方法，在单个应用中包含众多松散耦合且可单独部署的小型组件或服务
这些服务通常拥有自己的技术栈，包括数据库和数据管理模型；通过一个 REST API、事件流和消息代理组合彼此通信；以及按照业务能力进行组织，具有通常称为有界上下文的服务分隔线
面向过程 -> 面向对象
早期代码都是面向过程编程，多个业务近似的逻辑代码无法实现继承、封装困难
导致开发工作量巨大，维护性指数级增长
面向对象随之而来，增强了代码编写的可维护性、减少了大量开发时间成本
面向对象引入了许多新的概念，类、封装、多态、继承等
面向对象 -> 包/模块
随着业务线的增多、业务模块的迁移，面向对象的弊端也开始展现
对象间的依赖开始加深，导致对象无法实现单个对象的拷贝
产生拷贝的代码，若存在系统性的逻辑问题（BUG），因为复制粘贴，修复难度递增
故而衍生出，包/模块的管理工具，将整体逻辑服务能力，整合至 拓展包
包解决了 多个模块间的依赖管理、代码版本管理、整体迁移能力等多个问题
包/模块 -> 服务
包/模块，解决了工具属性的拓展包（框架）管理
但若业务层级的包/模块，也采用此方式的话，存在包变更频繁
每一次业务的调整，都需要各个依赖此业务的项目进行包的升级变更
进而 业务层级的模块，慢慢演变为 SOA 服务，通过远程调用的释放开发人员的负担
业务层级的模块，可以随时根据业务情况进行优化调整，而调用方无需关心 服务方的实现方式
此场景，与平时调用第三方 API 类似，都属于远端调用
第三方 API 可以释放开发人员大量的时间成本
服务 -> 微服务
随着 SOA 服务概念的兴起，普通的API服务也开始面临更多的挑战
服务的扩容成本高昂（一个服务项目占用大量内存、CPU、存储空间）
而往往扩容的需求，仅仅来源于几个处理逻辑
微服务的概念由此衍生，将大而全的服务细分，由多个微服务组成整体服务能力
微服务间通过特有的通讯方式（RPC）进行调用
从而避免了服务集群的一荣俱荣、一损俱损
由于使用了同一个内存环境、机器环境、公共逻辑代码，往往一个内容的崩溃导致整体服务的不可用
示例
双十一时期：
- 订单业务大幅增长 - 确保抢购流程
- 支付业务大幅增长 - 确保支付流程
- 资金流水查询延迟 - 让渡服务能力
- 农场、植树临时关闭 - 让渡服务能力
订单互通：
天猫、飞猪、淘宝、1688 … 各种淘系软件内的交易订单均可互通
构建订单中台，统一处理订单逻辑能力、及支付逻辑
做整体中台数据分析，实时统计订单销售总量、各平台总量
所有新增内容中，无需进行支付系统的对接，仅需跟订单系统做简单对接
为何选择微服务
业务驱动、业务增长
业务线快速拓展，出现更多重叠性的业务内容
早期重叠性业务内容解决主要依托多业务线数据库互相调用
由于互相依赖对方的数据库，但业务线又存在调整数据库结构的情况
单业务线调整时，容易影响到其他业务线，产生了更多的开发成本
业务核心聚合
随着业务线的发展，越来越多的重叠性业务展现
将核心重叠业务提炼、单独管理，成为基础服务能力，也迫在眉睫
通过微服务等概念驱动，逐渐剥离出中台相关服务能力
例如：产品服务、订单服务
订单自行与第三方支付平台进行对接，业务组仅需要接入订单系统即可完成整体能力
