SOA架构解析
SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”，它是一种设计理念，其中包含多个服务， 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间 通过网络进行调用。架构图如下：
跟 SOA 相提并论的还有一个 ESB(企业服务总线)，简单来说 ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通; 随着我们业务的越来越复杂，会发现服务越来越多，SOA架构下，它们的调用关系会变成如下形式：
很显然，这样不是我们所想要的，那这时候如果我们引入ESB的概念，项目调用就又会很清晰，如下：
SOA所要解决的核心问题
系统间的集成 : 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如 ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。
系统的服务化 : 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。
业务的服务化 : 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】。
微服务（Microservices）架构解析
微服务架构和 SOA 架构非常类似,微服务只是的 SOA 升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。 组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。若我们把 PC 中的各个组件以服务的方式构 建，那么这台 PC 只需要维护主板（可以理解为ESB）和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 需要调用 CPU 做计算处理，只需知道 CPU 这个组件的地址就可以了。
微服务的特征
通过服务实现组件化
按业务能力来划分服务和开发团队
去中心化
基础设施自动化(devops、自动化部署)
SOA 和微服务架构的差别
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时以 SOA 的思想进入到单个业务系统内部实 现真正的组件化。
Docker 容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以通过类似 Spring Boot 或者 Node 等技术独立运行。
还有一个点大家应该可以分析出来，SOA 注重的是系统集成，而微服务关注的是完全分离。
服务网格（Service Mesh）架构解析
17 年年底，非侵入式的 Service Mesh 技术慢慢走向了成熟。Service Mesh ，中文释义“服务网格”，作为服务间通信的基础设施层在系统中存在。如果要用一句话来解释什么叫 Service Mesh，我们可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务间的网络调用、熔断、限流和监控。我们都知道在编写应用程序时程序猿一般都无须关心 TCP/IP 这一层（比如提供 HTTP 协议的 Restful 应用），同样如果使用服务网格我们也就不需要关系服务间的那些原来是由应用程序或者其他框架实现的事情(熔断、限流、监控等)，现在只要交给 Service Mesh 就可以了。服务网格架构图如下：
目前流行的 Service Mesh 开源软件有Linkerd、Envoy和Istio，而最近 Buoyant（开源 Linkerd 的公司）又发布了基于 Kubernetes 的 Service Mesh 开源项目Conduit。
关于微服务和服务网格的区别，我这样理解：微服务更注重服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合等。
服务网格的特征
应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现