什么是SOA
SOA定义来讲：
- 将支持企业的IT业务系统分解为多个组件，让每个组件都独立的提供离散、自治、可复用的服务能力；
- 通过服务的组合和编排来实现上层的业务流程
总结起来就一句话，找到服务，组合和组装服务，实践原则：
- 业务能力组件化
- 组件能力服务化
- 服务能力可编排化
SOA 示例
下面以新公司注册为例说明下SOA，你要完成一个新公司注册一定涉及到根工商，税务，银行多个政府部门和金融单位业务协同才能完成。要完成协同首先各个业务部门要将自己能力暴露为服务，即找到服务的过程。
找到服务后，需要根据业务流程需要将服务组装起来，形成一个完整流程。
单体应用（业务系统）的缺点
- 单体应用虽然分了模块，但仍然是紧耦合，数据无法拆分，逻辑层代码包也无法拆；
- 扩展困难，特别是DB的扩展能力，不是简单的RAC／HA集群可以解决的；
从运行态的视角：
- DB走HA或RAC集群，但是扩展性是大问题，很多应用后期即使走了RAC也无法解决性能问题。
- 部署的是一个大WAR包，无法分模块独立分开部署。
- WAR部署当前可以是物理机，也可以是虚拟机，但是WAR包偏重，很少直接部署到Docker容器的。
- Application Server层的性能可以通过负载均衡方式进行水平扩展。
从设计态的视角：
- DB本身是无法拆分的，各个模块的数据库，视图全在一个大的SID或Schema里面。
- 模块之间的交互除了通过逻辑层外，还有些是直接通过DB层的跨表连接完成的。
- 逻辑层的模块和模块之间往往是紧耦合的，相互间的调用随意，很多都是内部API或方法调用。
什么是微服务？
SOA的时候都是谈业务系统间的服务共享和集成，即最小管理单位是业务系统，如采购系统、ERP系统；但是如果进一步我们将管理最小单元变化为组件，即采购系统里面的采购订单组件，供应商组件，那这就是SOA思想进一步内化到业务系统内部。而正是由于此，引出了微服务架构。
从运行态的视角：
- 数据库在部署的时候是可物理拆分的，即不同微服务模块的数据库可以独立部署。
- 微服务模块的应用组件包是独立部署的。
- WAR包由于已经按模块拆分为多个，因此每个WAR包相对来说更加轻，而容易部署到类似Docker容器上。
- 由于WAR包之间有接口交互和协同，需要增加微服务网关实现服务管理和治理。
从设计态的视角：
- 数据库，逻辑层和界面展现在设计的时候就是完全相对独立的一套。
- 逻辑层的各个组件之间只能通过Service API接口进行交互，微服务架构下推荐轻量Http Rest接口。
- 逻辑层各个模块之间彻底实现松耦合。各个模块本身也更加轻量。
