面向服务架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA（全称：Service Oriented Architecture），中文意思为 “面向服务的架构”，你可以将它理解为一个架构模型或者一种设计方法，而并不是服务解决方案。其中包含多个服务， 服务之间通过相互依赖或者通过通信机制，来完成相互通信的，最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用 。
跟 SOA 相提并论的还有一个 ESB（企业服务总线），简单来说ESB就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 可以简单理解为：它做了消息的转化解释和路由工作，让不同的服务互联互通；
更简单的理解就是内部服务通信和外部服务通信。
服务对外-------restful ，相当于ESB相当于kubernetes的ingress
内部服务通过消息中间件通信
SOA在C++服务领域如何设计
举个例子：一个写数据库操作的服务如何切分
接口层是一个so，写一个接口保证其他服务可以调用
数据库增删改查操作是一个公共的so，提供sql 公共接口
这样我们就把一个后台接口切分为两个模块，他们之间是通过动态库加载的形式通信、进程间通信。
当然如果模块本身是服务就会通过消息中间件进行通信。
SOA 所解决的核心问题
1.系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】
这里提到的有序就是何时http直连、何时走发布订阅机制，何时走多对多的发布订阅，结合业务开展。
2.系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生。目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】
公共模块的提取
3.业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；前面两步都是从技术层面来解决系统调用、系统功能复用的问题。第三步，则是以业务驱动把一个 业务单元封装成一项服务。这一步解决的核心问题是 【高效】
业务切割能力，需求分解，需求切割
微服务扫盲
微服务架构其实和SOA架构类似，微服务是在SOA上做的升华。微服务架构重点强调的一个是"业务需要彻底的组件化和服务化"，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这样的小应用和其他各个应用之间，相互去协作通信，来完成一个交互和集成，这就是微服务架构。
组件化：组件表示一个可以独立更换和升级的单元，就以PC机为例，PC中的 CPU、内存、显卡、硬盘一样，独立更换升级而不影响其他单元。如果我们把PC作为组件以服务的方式构建，那么这台PC只需要维护主板和一些必要的外部设备。CPU、内存、硬盘都是以组件方式提供服务，PC需要调用CPU做计算处理，只需要知道CPU这个组件的地址即可。
微服务的特征
- 1.通过服务实现组件化
- 2.按业务能力来划分服务和开发团队
- 3.去中心化
- 4.基础设施自动化（devops、自动化部署）
SOA 和微服务架构的差别
1.微服务去中心化，去掉ESB企业总线。微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化
2.Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node或者Spring Boot等技术跑在自己的进程中。
3.SOA注重的是系统集成方面，而微服务关注的是完全分离
个人认为这是软件层面差别，还有其他原因会导致SOA快速转为微服务架构
硬件资源飙升，足够的内存、硬盘、CPU多核、虚拟机
业务需求导致服务体量增长巨大，SOA维护成本太高
今天做笔记学到了一个东西分享一下
我们大多数人在做架构设计的时候都会忽略一个最重要的点：数据模型。
数据模型是软件产品端到端的核心数据流
数据模型是数据的核心，数据的抽象
数据模型是模块间交互的标准
对数据模型的理解从一定程度上反应了对业务的理解
设计加入深刻的数据模型这个理念尤为重要
再回到经典的单体架构MVC
MODEL
VIEW
Controller
我们在套回架构设计：
VIEW约等于Client
Controller约等于架构SOA /Kubernetes/Serverless
MODEL等于数据模型
我们说做一件事最简单的原则就是搞清楚：
哪些物体在哪些渠道传送哪些数据模型
物体集合是什么，如何抽象和实例化
传送渠道有哪些，如何抽象和实例化
数据模型有哪些，如何抽象和实例化
小学作文怎么写：总分总
架构设计怎么做：总分总
如何分析一个人：总分总
团队如何往前走：总分总
总的来说这件事有1234567
分开说1有1234567，2有1234567...
总得来说1234567都是数字，但又各不相同
需求何时可以开发
最小颗粒度
如何确认最小颗粒度
需求分析 需求澄清 反复迭代
直到需求澄清人可以将复杂东西小白话讲解
直到需求承接者理解最小的backlog
