微服务架构和soa服务架构区别

1、微服务和soa区别
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
（1）SOA 和微服务是一脉相承的，微服务是 SOA 思想的一种提炼，是经过良好架构设计的 SOA，使用一系列微小服务来实现单个应用的方式，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署。

（2）微服务与敏捷开发的思想高度结合在一起，微服务框架将能够带来更大的敏捷性，并为构建应用提供更轻量级、更高效率的开发，而 SOA 更适合大型企业中的业务过程编排、应用集成。

（3）从服务粒度上，SOA 的服务粒度要粗一些，而微服务倡导服务的细粒度，专注于服务的拆分，重用组合，服务粒度足够小到不能再进行拆分，而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度。微服务是以 SOA 的思想进入到单个业务系统内部实现彻底的组件化和服务化，原有的单个业务系统拆分为多个可以独立开发、设计、运行和运维的小应用，这些小应用可独立地进行开发、管理和加速，应用之间通过服务完成交互和集成，每个小应用除了完成本身的业务功能外，还需要消费外部其它应用暴露的服务，同时也将自身的能力朝外部发布为服务。
（4）去中心化：SOA 注重的是系统集成，而微服务关注的完全分离，微服务架构采用去中心化思想，服务之间采用统一的协议和格式，例如 REST、RPC 等轻量协议通信，相比 ESB 更轻量。为了统一管理微服务系统，可以部署一个统一的网关，作为系统的唯一入口。网关封装了系统内部架构，为每个客户端提供一个定制的API。除此之外，网关还可以用于身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。两者的架构如下图所示：

SOA 更适合需要与许多其他应用程序集成的大型复杂企业的应用程序环境，小型应用程序不适合 SOA 架构，因为它们不需要消息中间件组件。而微服务架构，更适合于较小和良好的分割，基于Web的系统。如果你开发的是互联网应用，并且没有历史遗留问题，请优先考虑采用微服务架构。

3：微服务框架
市面常用微服务框架有：Spring Cloud 、Dubbo 、kubernetes

从学习成本上考虑，Dubbo 版本趋于稳定，稳定完善、可以即学即用，难度简单，Spring cloud 基于Spring Boot，需要先掌握Spring Boot ，例外Spring cloud 大多为英文文档，要求学习者有一定的英文阅读能力
从开发风格考虑，Dubbo倾向于xml的配置方式，Spring cloud 基于Spring Boot ，采用基于注解和JavaBean配置方式的敏捷开发
从开发速度上考虑，Spring cloud 具有更高的开发和部署速度
从通信方式上考虑，Spring cloud 基于HTTP Restful 风格，服务于服务之间完全无关、无耦合。Dubbo 基于远程调用，对接口、平台和语言有强依赖性，如果需要实现跨平台，需要有额外的中间件。
所以Dubbo专注于服务治理；Spring Cloud关注于微服务架构生态。
4：服务通信RPC和HTTP
在单体应用中，各模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是微服务应用是运行在多台机器上的，一般来说，每个服务实例都是一个进程。微服务必须使用进程间通信机制来交互。而常见的通信协议主要有 RPC 和 REST 协议。

REST 和 RPC 都常用于微服务架构中，微服务的好处之一，就是不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦。 但是，如果没有统一的通信框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等 “业务之外” 的重复技术劳动，造成整体的低效。所以，统一通信框架把上述 “业务之外” 的技术劳动统一处理，是服务化首要解决的问题。
（1）REST：

REST 是一种架构风格，指的是一组架构约束条件和原则，满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源，它是通过 HTTP 协议实现，使用 HTTP 协议处理数据通信，更标准，更通用，因为无论哪种语言都支持 http 协议。常见的 http API 都可以称为Rest 接口。REST 提供了一系列架构系统参数，作为整体使用，强调组件交互的扩展性、接口的通用性、组件的独立部署、以及减少交互延迟的中间件，它强化安全，也能封装遗留系统。

（2）RPC：

RPC 是一种进程间通信方式。允许像调用本地服务一样调用远程服务，通信协议大多采用二进制方式。RPC 框架的目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发者在使用时只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率。

灵活性方面：在微服务架构中，各个服务间千差万别，REST 的调用和测试都很方便，但使用 RPC 则会有很多约束。
性能方面：RPC 协议性能更高，如果算上序列化，吞吐量大概能达到 REST 的二倍，响应时间也更为出色。
开放与通用性：REST 通过 http 实现，相对更加规范与通用，无论哪种语言都支持 http 协议。而如果 RPC 需要对外开放的话，需要进一步处理。所以如果是对外开放的 API，一般使用 REST 协议，内部服务的调用则采用性能更高的RPC方式。
代码的耦合度：RPC 与代码的耦合度高，而 REST 对代码松散耦合。