http://bbs.chinaunix.net/thread-4255092-2-1.html

 

1. 你了解微服务吗?SOA和微服务有何差异?
微服务架构被认为是目前最适合开发高可扩展性应用的架构风格,微服务架构致力于解决大型、复杂的应用的各种问题。它是一种基于服务的架构,这些服务可独立部署,作为基础的组件。微服务架构在整个开发、测试等开发周期中提供了更好的控制,但它在服务分类方面有一些限制。微服务架构还使用了服务间的通信协议(REST、JSON等)。
SOA架构可以由多种定义方式,这是因为SOA架构风格一直在不断地发展演进。它为企业级软件的复杂组合带来了秩序——通过把它们表示为服务的集合。SOA还使用了服务通信协议,SOA可以被认为是微服务的超集。
SOA架构依赖于共享数据模型。此模型在大量数据结构和模型和分层之间有复杂的关系。SOA的分层组织结构有利于服务协调和消息通信功能。
SOA是基于共享数据模型的,因此,可以预估它在服务和其它系统组件之间存在数据紧耦合的现象。这使得它难以做改变。一些附带的重测是必要的,以确保改变不影响现有的任何服务。
微服务架构存在上下文边界的概念,这使得它在单个服务和数据之间存在关联。
SOA架构的多层模型以中央的消息通信中间件层为主要特征。而对于微服务架构,在组成应用的各种服务之上就存在一个非协调的API层。
通过一个中央集线控制器,SOA维护了服务执行的顺序。而微服务使用了服务间的通信协议来维护服务执行的顺序。
SOA架构致力于解决在复杂的企业系统中的异构应用,促成跨应用和功能的共享服务。而微服务架构是面向基于Web的、更小的、不太复杂的应用程序的最佳架构方式,这些应用程序不需要明确的服务协调。

2. 到底在什么样的情况才适合使用微服务架构?
如果遇到了以下的情况,应该采用微服务架构:
1)系统越来越庞大,新功能开发或修改功能变得越来越耗时
2)系统的复杂度极高,模块间紧耦合严重,整体扩展性差
3)系统性能不高,通过扩展也难以提升性能
4)系统的可维护性越来越差

3. 服务与服务之间的事务怎么做?接口的调用权限如何控制,粒度在方法级别的?
我通常是这么解决的。在基础服务的上层封装面向事务处理的服务(这里我称为A服务),A服务依赖于下层的多个基础服务,一个A服务就是一个完整的事务处理过程,它内部是调用下层的多个服务共同完成功能的。如果A服务执行失败,则做相应的回退等处理;如果A服务执行成功,那么继续。
微服务架构的服务之间的调用,可以通过REST接口,还可以用RPC、消息通信等方式。以REST接口为例,服务间通过内网或专线方式进行调用,以保证速度。对外则使用API网关来做访问控制。

4. 为什么有人说“玩不起”?较比普通架构需要多做那些工作?
微服务架构要设计好并不容易。我的建议是根据具体的需求具体分析,通用的原则也不少。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

难以对比 SOA 和微服务的原因在于,它们的定义留有很大的解释空间。如果您仅拥有这两个概念的表面知识,可能会觉得它们很相似。一些关键方面(比如组件化、解耦和标准化通信协议)描述了最近几十年的大部分软件举措,所以我们需要进行更深入地分析。

 

考虑以下简单定义:

 

  • 微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、完全独立的组件,这使得它们拥有更高的敏捷性、可伸缩性和可用性。

  • SOA将应用程序的功能公开为更容易访问的服务接口,使得在下一代应用程序中使用它们的数据和逻辑变得更容易。


     

 

如下图演示了这些定义。SOA 似乎拥有 企业范围,应用程序在该范围内彼此通信。SOA 通过应用程序之间的标准化接口来公开服务。微服务架构似乎拥有 应用程序范围,仅关注一个应用程序内的结构和组件。

--------------------- 本文来自 ztguang 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/ztguang/article/details/52894794?utm_source=copy

10-03 14:07