SOA和微服务区别
一、Scale Cube
通过上图我们发现如果对巨石型（单体架构）的应用进行扩展、性能提升可以通过三种X、Y、Z三种方式，具体如下：
- X轴：水平扩展能力，即通过负载均衡实现水平扩展；
- Y轴：应用分解，即将单体应用分解为多个模块（服务于）；
- Z轴：数据拆分，即将数据分开存储，比如分库分表或者不同存储方式组合（oss、db、redis等）；
二、单体架构
单体架构是将所有功能都集成、部署在一个工程（应用）里面，比如web应用程序发展早期，大部分web工程是将所有功能模块打包到一起并放在一个web容器中运行，很多企业的java应用程序打包为war包。单体架构有很多好处：容易开发、测试、部署；缺点很明显，部分功能的变化都要导致项目重新打包，还有就是性能瓶颈。
从图中可以发现，订单数据、用户数据和商品数据的操作都放在一个应用里面。
三、SOA
SOA（面向服务的架构）是集成多个较大组件（应用）的一种机制，它们将整体构成一个彼此协作的套件。比如企业ERP、CRM、OA等系统一般都是由不同供应商开发的，技术差别和系统接口差异比较大，系统之间互相访问困难，于是就出现了esb（企业服务总线），统一访问的方式。这个就是SOA的探索，所以SOA强调的是系统之间的协作，访问方式的统一。
如上图，订单系统、用户系统、商品系统是互相独立的系统，他们之间通过esb进行访问、协作。
四、微服务
4.1 微服务介绍
微服务的概念是由Martin Fowler提出，微服务有很多的参考原则，但并没有明确提出微服务架构的最佳实践。SOA 和微服务架构这两个概念成型的年代不一样，实践的主体、要解决的问题也是不一样的。
微服务架构则是在互联网相当成熟的时代，互联网业务规模增长快，变更多且频繁，互联网技术团队强烈关注 DevOps 和持续交付这样的研发理念，传统的单体架构无法满足迭代速度、系统扩展性、资源利用率优化等需求，微服务架构就闪亮登场了，通过解耦，解决掉各种难题。
在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用。每个组件都被称为微服务而每个微服务都在整体架构中执行着单独的任务，负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，以执行较大应用需要完成的具体任务。
微服务的成功，不仅在于架构的先进性能够匹配当前的业务痛点，更在于开源微服务框架之外，容器云等等配套的工具链也已经成熟。微服务不是单独存在的，要配合容器编排、APM、CI/CD（持续集成/持续交付）、自动化测试。微服务实践往往都是 Kubernetes 容器平台、微服务治理框架和 DevOps 系统一起上的。
综上所述，微服务的几个关键点如下：
- 微服务有明确的参考原则，但是没有明确的实践
- 微服务的应用场景是规模大、频繁变更，不要为了微服务而微服务
- 微服务架构强调的是整个架构体系，运维、开发、集成等
4.2 微服务架构
微服务架构通常都会包括注册中心、网关、容器服务、DevOps、自动化测试等模块。常用的微服务框架有spring cloud等。
- 使用API网关
使用网关可以规范服务调用接口，统一处理限流，降级策略等，减少每个微服务的负担。
- 微服务使用独立数据库
每一个微服务只能访问自己的数据库，不同的微服务不可以访问其他的数据库，不同的微服务根据实际情况可以选择不同的存储技术。