部分资料在网上收集整理，如有侵权联系删除
系统应用架构的变迁
第一代：单体架构
将所有功能模块打包到一起，并放在一个容器中运行。
比如，搭建有一个物质管理系统：资产盘点、出入库、定位、维修、报废等一系列操作。在使用单体架构时，那么就是将这一系列服务都放在一个服务器中，这种将所有功能部署在一个容器中运行的系统就叫单体架构。
| 优点 | 缺点 |
|---|---|
| 容易测试，在本地就可以启动完整的系统 | 需求的增加，不断往容器中添加服务，显得臃肿笨拙 |
| 容易部署，直接打包为一个完整的包，拷贝到容器中即可运行 | 修改一个地方则需要整个系统重新部署 |
| 容易开发：开发方式简单，方便运行和调试（适用于较为简单的系统） | 不利于更新技术框架，除非将系统重构 |
| . | 维护成本大，扩展性差 |
第二代：面向服务架构（SOA）
在了解SOA之前，先简单了解企业服务总线
企业服务总线（ESB）：
ESB是面向服务架构(SOA)的核心构成部分，指传统数据连接技术（web、xml、中间件技术）结合的产物，简单来说，就是一根管道，用来连接各个服务节点，为了集成不同系统，不同协议的服务，服务总线做了消息的转化解释和路由工作，让不同的服务互联互通；是一个具有标准接口、实现了互连、通信、服务路由。
总线需要具备的功能：
1、服务统一管理：为整个系统提供一个统一、标准。可靠 、可扩展的服务管理平台。
2、集成服务：提供基础的服务与定制的服务，支持集成服务模式，支持服务的分解，服务调度和路由、封装及组合。
3、公用服务：提供内置的各种公共服务，如，认证服务、日志服务等。
4、服务协议转换：通过把不同的通信协议转换为标准的报文，屏蔽异构系统的底层技术差异。
5、服务监控：提供服务等级管理及流量管理。
6、安全体系：提供多种安全机制并支持和第三方安全系统的有效集成。
SOA是集成多个较大组件（一般是应用）的一种机制，将整体构成一个彼此协作的套件，一般来说，每个组件会从始至终执行一个完整的业务逻辑。SOA中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间，通过网络调用。
特点：
1、系统集成：从系统角度讲，解决了企业系统与系统间通信问题，把原来散乱、无规划的系统间的网状结构梳理成规整，可治理的系统。在梳理时则需要引用一些产品，
常用的是企业服务总线（ESB）、技术规范、服务管理规范。主要解决核心问题，无序变有序。
2、系统的服务化：从功能角度讲，把业务转换成可复用、可组装的服务，通过服务的编排实现业务的快速复制。目的是把原先固有的业务功能转变为通用的业务服务，实现快速复用。主要解决的核心问题，原来固有业务可复用。
3、业务的服务化：从企业的角度讲，把原来职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力。把一个业务单元封装成一项服务。主要解决的核心问题是高效。
| 优点 | 缺点 |
|---|---|
| 数据统一，共享数据库，使服务接口使用同一的数据模型的数据，确保数据一致性 | 技术不匹配，在某些情况并不能轻松对操作平台进行重新打包，原因是业务功能结构需求不匹配 |
| 灵活性较高，缩短产品和服务的上线时间，降低了开发与改变流程的成本 | 系统间交互需要使用远程通讯 ，一定程度上降低了响应速度 |
| 系统由子系统组成，系统易于重构 | . |
第三代：微服务架构
跟SOA类似，在SOA上做了升华，微服务架构强调业务需要彻底的组件化和服务化，在微服务架构中，系统的业务逻辑被拆分成为一系列小而松散耦合的分布式组件（组件一般指应用），共同构成较大的应用。每个组件都被称为微服务，而每个微服务都在整体架构中执行着单独的任务或单独的功能。每个微服务可能会被一个或多个其它微服务调用，以执行较大应用需要完成的具体任务。
比如：假设一个APP中有积分体系功能，现需要更新积分，只需要更新发布积分的微服务即可，其他的功能正常运行，不受影响。而不是将整个业务系统都停掉，所有的功能都要暂停一会儿，等发布积分的服务才能使用。
特点：
1、通过服务实现组件化，开发者不再需要协调其它服务部署对本服务的影响。
2、按业务能力来划分服务和开发团队，开发者可以自由选择开发技术，提供API服务 即可。
3、去中心化:
- 每个微服务都有自己私有的数据库来持久化业务数据。
- 每个微服务只能访问自己的数据库，而不能访问其他服务的数据库。
- 某些业务场景下，需要在一个事务中更新多个数据库，这种情况也不能直接访问其它微服务的数据库。
- 降低微服务之间的耦合度，不同服务可以采用不同的数据库技术。在复杂的的业务场景下，如果包含多个微服务，通常在客户端或者中间层(网关)处理。
| 优点 | 缺点 |
|---|---|
| 部署简单，每个服务承担少数职责，波及范围小 | 系统整体延迟增加，原来的函数调用改为服务调用 |
| 易于扩展，某一项服务的性能达到瓶颈，只需增加该服务的节点数即可，其它服务不改变 | 每个服务都需要单独部署，运维、测试成本增加 |
| 减低资源的耦合性，服务独立，数据源唯一 | 前期服务的定义和拆分需要较大工作量 |
| 易于维护，每个微服务的职责单一，复杂性降低，不会牵一发而动全身 | . |
面向服务架构(SOA)与微服务的主要区别：
| 功能 | 面向服务(SOA)架构 | 微服务架构 |
|---|---|---|
| 耦合性 | 一般是松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
| 系统组成 | 由多个子系统组成 | 由多个组件组成 |
| 应用部署 | 相互依赖，部署复杂 | 独立部署，互不影响 |
| 数据管理 | 全局数据模型，共享数据库 | 每个服务都有自己的数据模型或数据库 |
| 服务架构 | 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
中台
中台并非完全是自上向下的战略设计，也非是为了追随行业风口，可以理解为一种产品设计思路或系统架构的思路。
中台是随着公司业务高速发展，组织不断膨胀的过程中暴露的问题需要解决。将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新。
中台做到前后分离，后台统一提供数据接口，前台实现业务流转。
中台与微服务的区别：
中台是提升企业的能力的复用，一种方法论/思想。
微服务是独立开发、维护、部署的小型业务组件，一种技术架构。
中台与微服务的关系：
微服务架构，是实现中台思想的落地的重要手段。
中台解决的核心问题：
为减少重复业务系统开发及实现系统数据共享一个技术平台底座，将多年技术沉淀的价值最大化，统一各个业务部门或系统重复使用、重复建设的功能和系统统一规划和管理。
什么时候需要中台：
如阿里：淘宝，有订单、库存、评价、积分、物流等业务系统。天猫也有订单、库存、评价、积分、物流等业务系统。1688，也有类似业务系统。多个系统有重复业务系统需要建设，且系统间数据不能完全共享，系统各自运行。此时使用技术中台以及业务中台，来实现业务重用及数据共享，把技术沉淀价值最大化。
借用网上的回复：
微服务就是：将整个军队分散为若干军区，每个军区之间确定各自驻防的边界划分，至于各军区如何行军、如何存放军火、如何部署兵力，不作统一规定，各军区自行决断，各军区的人当然也不能进入其他军区的地盘，但各作战单位必须遵守共同的通讯频道，必须满足对其他军区的服务契约。
中台就是：建立强大的火箭军、炮兵。空军。无人机部队、信息化部队等，如此一来，前方作战小分队可以很小，一个班的人要攻打一个山头，只要侦查清楚这个山头的特定地形和敌军布防，然后就根据情况呼叫空军地毯式轰炸。呼叫炮兵火力覆盖、呼叫无人机定点清除、呼叫信息化部队电子干扰...一个班就可以搞定。
虽然这两个概念并不互斥，但是微服务听起来更像是【守城】，就是对现有地盘的加强和巩固。而中台更支持【开拓】，主要目的是更灵活的拓展新的业务。
如有错误，望指正
