0.前言
在深入探讨微服务和SOA之间的区别之前，让我先告诉您单片体系结构、SOA和微服务之间的基本区别：
一个整体类似于一个 大容器 ，其中应用程序的所有软件组件都被组装在一起并紧密打包。
面向服务的体系结构本质上是 服务的集合 。这些服务相互通信。通信可以涉及简单的数据传递，也可以涉及协调某些活动的两个或多个服务。需要一些将服务相互连接的方法。
微服务，又名微服务架构，是一种架构风格，它将应用程序构造为围绕业务领域建模的小型自治服务的集合。
1.SOA架构和微服务架构的区别
首先SOA和微服务架构是一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。
（1）SOA（Service Oriented Architecture）“面向服务的架构”:是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。
SOA定义了四种基本服务类型，如下所示：
Business Services：
定义核心业务操作的粗粒度服务。
通过XML、业务流程执行语言（BPEL）等表示。
Enterprise Services：
实现业务服务定义的功能。
主要依靠应用服务和基础设施服务来满足业务需求。
Application Services：
仅限于特定应用程序上下文的细粒度服务。
专用用户界面可以直接调用服务。
Infrastructure Services：
实现非功能性任务，如身份验证、审核、安全性和日志记录。
可以从应用程序服务或企业服务调用。
（2）微服务架构：和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
其中，功能服务：
- 支持特定的业务操作。
- 服务的访问是在外部完成的，这些服务不与其他服务共享。
- 与SOA一样，基础设施服务实现审核、安全和日志记录等任务。
- 在这种情况下，这些服务不会对外公布。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
2.ESB和微服务API网关
（1）ESB（企业服务总线），简单来说ESB就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。
（2）API网关:API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
3.SOA架构特点：
系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】
系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】
业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
4.微服务架构特点：
（1）通过服务实现组件化
开发者不再需要协调其它服务部署对本服务的影响。
（2）按业务能力来划分服务和开发团队
开发者可以自由选择开发技术，提供 API 服务
（3）去中心化
每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
（4）基础设施自动化（devops、自动化部署）
的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
5.主要区别：
换个维度的对比：
微服务和SOA在细节上的主要区别
（1） 服务粒度 ：microservices体系结构中的服务组件通常是 单用途 的服务，它们可以非常非常好地完成一件事情。使用SOA，服务组件的大小可以从小型应用程序服务到非常大型的企业服务。事实上，在SOA中有一个由大型产品甚至子系统表示的服务组件是很常见的。
（2）组件共享 ：组件共享是SOA的核心原则之一。事实上，组件共享是企业服务的全部内容。SOA增强了组件共享，而MSA则试图通过 bounded context（有界上下文 ）来最小化共享。有界上下文是指组件与其数据作为一个具有最小依赖性的单个单元的耦合。由于SOA依赖于多个服务来满足业务请求，因此基于SOA构建的系统可能比MSA慢。
（3）中间件 vs API层 ：microservices架构模式通常有一个API层，而SOA有一个消息中间件组件。SOA中的消息传递中间件提供了MSA(Micro Service Architecture)中没有的许多附加功能，包括中介和路由、消息增强、消息和协议转换。MSA在服务和服务使用者之间有一个API层。
（4）远程服务 ：SOA架构依赖于消息传递（ AMQP 、 MSMQ ）和 SOAP 作为主要的远程访问协议。大多数MSA依赖于两种协议：REST和简单消息传递（ JMS 、 MSMQ ），MSA中的协议通常是同构的。
（5）异构互操作性 ：SOA通过其消息中间件组件促进多种异构协议的传播。MSA试图通过减少集成选择的数量来简化体系结构模式。如果您想在异构环境中集成使用不同协议的多个系统，您需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议公开和访问，那么MSA是更好的选择。
最后，判断哪种体系结构比另一种更好并不是那么简单。这主要取决于您正在构建的应用程序的用途。 SOA更适合于需要与许多异构应用程序集成的大型复杂业务应用程序环境； 较小的应用程序不适合SOA ，因为它们不需要消息传递中间件组件。另一方面， 微服务更适合于更小的、分区良好的、基于web的系统 ，在这些系统中，作为开发人员，微服务给了您更大的控制权。结论是，由于它们都具有不同的体系结构特征，所以这主要取决于所构建的应用程序的用途。
6.Dubbo服务的最佳实践
（1）分包
服务接口、请求服务模型、异常信息都放在api里面，符合重用发布等价原则，共同重用原则
api里面放入spring 的引用配置。 也可以放在模块的包目录下。
（2）粒度
尽可能把接口设置成粗粒度，每个服务方法代表一个独立的功能，而不是某个功能的步骤。否则就会涉及到分布式事务
服务接口建议以业务场景为单位划分。并对相近业务做抽象，防止接口暴增
不建议使用过于抽象的通用接口 T T<泛型>，接口没有明确的语义，带来后期的维护
（3）版本
每个接口都应该定义版本，为后续的兼容性提供前瞻性的考虑 version （maven -snapshot）
建议使用两位版本号，因为第三位版本号表示的兼容性升级，只有不兼容时才需要变更服务版本
当接口做到不兼容升级的时候，先升级一半或者一台提供者为新版本，再将消费全部升级新版本，然后再将剩下的一半提供者升级新版本
（4）预发布环境
推荐用法
在provider端尽可能配置consumer端的属性
比如timeout、retires、线程池大小、LoadBalance
（5） 配置管理员信息
application上面配置的owner 、 owner建议配置2个人以上。因为owner都能够在监控中心看到
（6）配置dubbo缓存文件
注册中心的列表
服务提供者列表
参考文献：
http://www.uml.org.cn/zjjs/201708083.asp
https://zhidao.baidu.com/question/1899225333752310100.html
http://blog.sina.com.cn/s/blog_493a84550102wq50.html
https://blog.csdn.net/MXC1146/article/details/118358867
37
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
