微服务是SOA的升级版，做到更细的粒度，处理了更多的问题。
例如现在的微服务都会侧重解决：
服务发现、负载均衡、服务高可用、分布式请求日志跟踪
回答这个问题就像php和java谁更优秀一样,官方有说soa的拆分粒度一定比微服务大?官方有说soa一定要用webservice?官方有说soa只能用在企业服务微服务只用在互联网?官方有说soa一定要使用esb?soa就不能高可用,不能分布式,不能服务注册发现?
面向服务和面向数据！
大部分公司并不需要微服务
先说观点：对传统的微服务做法不是很看好。但是对竖直拆分+用jar包组装这种方式很看好
soa --- 性能低，开销大，开发成本高（需多个项目），无事务支持，模块化成都高
jar包组合 --- 性能高，开销低，开发成本高（需多个项目），有事务支持，模块化程度高
接口 --- 性能高，开销低，开发成本低，有事务支持，模块化程度不高容易被突破
微服务就是SOA的子集
SOA与微服务不存在冲突问题，他们是相辅相承的！ SOA不是针对某一个系统的架构设计，他更多是针对整个企业的架构设计，他所解决的是更高层的整个企业各业务领域的整合问题。其实微服 务的概念非常像早期的Cobra，微服务是针对某单一业务功能的原子化架构设计，是解决下层具体业务实现的架构设计方法。微服务的颗粒度要求是一个funtion（）这样的级别，一个单独的funtion是不能匹配业务的，那么肯定需要在其上层有一个实现调度的东西，Api Gateway就被提出来了。Api Gateway的主要作用是管理api,调度，转换，拼装，这这些是不是很熟悉？没错，它就是SOA架构中的核心:企业服务总线的作用。因此，微服务负责访问数据库封装成服务，服务被注册到esb，在esb中被转换和拼装，然后再给界面层使用。
最准确的说法：微服务是SOA的一种实现
最符合实际的说法：微服务是去ESB的SOA
背后实际上是两种思想的分歧：分布还是集中
当然这里说的不是服务的分布和集中。服务肯定是分布的，这是大前提，是SOA的本质理念之一。分歧在于对服务的治理，是分布还是集中。
很久以前的一天，Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下，然后告诉了好友，好友说，这不是新鲜东西，早有人总结了，叫做 SOA。Martin 很高兴，开始在公司内外推广 SOA。结果，不停有人质疑和挑战他。你这不是 SOA 吧？SOA 这里应该是如此这般的。对，这里我对 SOA 的理解是这样的。你看，这本 SOA 的书说的和你说的有出入。粒度？SOA 没有谈到这个呀，你这不是 SOA。分层跟 SOA 没有关系，你为什么要说这个呢？…Martin 没办法，心一横，老子就叫它 Martin's SOA。老子发明的词，老子就是最高权威，有最终解释权。还有谁不服？同事们一看，这思想本身很不错，值得推广，但叫 Martin's SOA 太没品了吧？还是要取个好一点的名字，最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了，又新，又有服务含在其中。Martin 忿忿地接受了这个建议，心里想着：妈的，明明就是 SOA，一群傻逼非要逼我取个新名字。后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战，所以每次要提一个什么概念，都去发明一个新词，免得一群人在那一边质疑挑战，一边大谈“我的理解”。这就是微服务、敏捷、精益企业、持续集成、持续交付背后的故事。一个名词产生之后，命名者的解释权就会随着时间而弱化（比如 Cooper 发明的 Persona 就被无数设计师乱用）。敏捷已经有点烂了，等微服务也烂了，我们还会发明新词。实在没辙，都是被逼的啊。
以一个公司为例：有基层员工 有管理层 有老板，最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越多，管理也很混乱，就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转；上述就是我理解的SOA的概念微服务没有具体的实施过，通过自己的一些理解尝试解释一下，勿喷！微服务有一定SOA的概念在里面，只是在粒度中，微服务更加小一点，比如说用户业务服务：登录 注册 个人中心 包含3个业务，都有userService 提供的，但是在微服务中，登录会被独立出来一个服务，注册也会被独立出来，相对SOA的粒度更新，业务场景耦合更低；另外微服务强调一个去中心化，上述的公司的组织架构会被打散，没有老板，没有管理层，每一个人都是一个服务，做着自己的事情，虽然没有完全想明白，把自己的理解放出来，大家可以探讨一下
首先，可以肯定的是SOA和微服务的确是一脉相承的，大神Martin Fowler提出来这一概念可以说把SOA的理念继续升华，精进了一步。其核心思想是在应用开发领域，使用一系列微小服务来实现单个应用的方式途径，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署 ，可以是使用不同的编程语言编写。而SOA可能包含的意义更泛一些，更不准确一些。其次，从实现方式上，两者都是中立性，语言无关，协议跨平台，相比SOA，微服务框架将能够带来更大的敏捷性，并为你构建应用提供更轻量级、更高效率的开发。而SOA更适合大型企业中的业务过程编排、应用集成。另外还有微服务甚至是去ESB、去中心化、分布式的，而SOA还是以ESB为核心，大量的WS标准实现。再次，从服务粒度上，既然是微，必然微服务更倡导服务的细粒度，重用组合，甚至是每个操作（或方法）都是独立开发的服务，足够小到不能再进行拆分。而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度，微服务更多为了可扩充性、负载均衡以及提高吞吐量而去分解应用，但同时也引发了打破数据模型以及维护一致性的问题。最后，从部署方式上，这个是最大的不同，对比Monolithic（有人翻译为单体）的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个 全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
SOASOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。当然企业还需要对服务治理，比如服务注册库，监控管理等。我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。微服务而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。这就是我对SOA和微服务架构区别的一点理解。
SOA：面向服务架构，java级企业开发的首选。微服务：采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！SOA我想我就不用细说了，使用java EE开发过的都知道其中的具体流程和步骤，J2EE的确在统一开发中有着很好的使用，但是随着模块功能的不断扩展或者变动，对于其中一点的维护可能会影响到整体的项目。所以有了微服务，彻底的将耦合性再次的降低了。为什么要讲我实习呢，因为微服务的使用会随着单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。 必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。所以自动化运维是十分必要的。总的说来，微服务有以下几个特征：1. 通过服务实现组件化；2. 按业务能力来划分服务与组织团队；3. 服务即产品；4. 智能终端与哑管道；5. 去中心统一化；6. 基础设施自动化；7. Design for failure；8. 进化设计
例如现在的微服务都会侧重解决：
服务发现、负载均衡、服务高可用、分布式请求日志跟踪
回答这个问题就像php和java谁更优秀一样,官方有说soa的拆分粒度一定比微服务大?官方有说soa一定要用webservice?官方有说soa只能用在企业服务微服务只用在互联网?官方有说soa一定要使用esb?soa就不能高可用,不能分布式,不能服务注册发现?
面向服务和面向数据！
大部分公司并不需要微服务
先说观点：对传统的微服务做法不是很看好。但是对竖直拆分+用jar包组装这种方式很看好
soa --- 性能低，开销大，开发成本高（需多个项目），无事务支持，模块化成都高
jar包组合 --- 性能高，开销低，开发成本高（需多个项目），有事务支持，模块化程度高
接口 --- 性能高，开销低，开发成本低，有事务支持，模块化程度不高容易被突破
微服务就是SOA的子集
SOA与微服务不存在冲突问题，他们是相辅相承的！ SOA不是针对某一个系统的架构设计，他更多是针对整个企业的架构设计，他所解决的是更高层的整个企业各业务领域的整合问题。其实微服 务的概念非常像早期的Cobra，微服务是针对某单一业务功能的原子化架构设计，是解决下层具体业务实现的架构设计方法。微服务的颗粒度要求是一个funtion（）这样的级别，一个单独的funtion是不能匹配业务的，那么肯定需要在其上层有一个实现调度的东西，Api Gateway就被提出来了。Api Gateway的主要作用是管理api,调度，转换，拼装，这这些是不是很熟悉？没错，它就是SOA架构中的核心:企业服务总线的作用。因此，微服务负责访问数据库封装成服务，服务被注册到esb，在esb中被转换和拼装，然后再给界面层使用。
最准确的说法：微服务是SOA的一种实现
最符合实际的说法：微服务是去ESB的SOA
背后实际上是两种思想的分歧：分布还是集中
当然这里说的不是服务的分布和集中。服务肯定是分布的，这是大前提，是SOA的本质理念之一。分歧在于对服务的治理，是分布还是集中。
很久以前的一天，Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下，然后告诉了好友，好友说，这不是新鲜东西，早有人总结了，叫做 SOA。Martin 很高兴，开始在公司内外推广 SOA。结果，不停有人质疑和挑战他。你这不是 SOA 吧？SOA 这里应该是如此这般的。对，这里我对 SOA 的理解是这样的。你看，这本 SOA 的书说的和你说的有出入。粒度？SOA 没有谈到这个呀，你这不是 SOA。分层跟 SOA 没有关系，你为什么要说这个呢？…Martin 没办法，心一横，老子就叫它 Martin's SOA。老子发明的词，老子就是最高权威，有最终解释权。还有谁不服？同事们一看，这思想本身很不错，值得推广，但叫 Martin's SOA 太没品了吧？还是要取个好一点的名字，最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了，又新，又有服务含在其中。Martin 忿忿地接受了这个建议，心里想着：妈的，明明就是 SOA，一群傻逼非要逼我取个新名字。后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战，所以每次要提一个什么概念，都去发明一个新词，免得一群人在那一边质疑挑战，一边大谈“我的理解”。这就是微服务、敏捷、精益企业、持续集成、持续交付背后的故事。一个名词产生之后，命名者的解释权就会随着时间而弱化（比如 Cooper 发明的 Persona 就被无数设计师乱用）。敏捷已经有点烂了，等微服务也烂了，我们还会发明新词。实在没辙，都是被逼的啊。
以一个公司为例：有基层员工 有管理层 有老板，最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越多，管理也很混乱，就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转；上述就是我理解的SOA的概念微服务没有具体的实施过，通过自己的一些理解尝试解释一下，勿喷！微服务有一定SOA的概念在里面，只是在粒度中，微服务更加小一点，比如说用户业务服务：登录 注册 个人中心 包含3个业务，都有userService 提供的，但是在微服务中，登录会被独立出来一个服务，注册也会被独立出来，相对SOA的粒度更新，业务场景耦合更低；另外微服务强调一个去中心化，上述的公司的组织架构会被打散，没有老板，没有管理层，每一个人都是一个服务，做着自己的事情，虽然没有完全想明白，把自己的理解放出来，大家可以探讨一下
首先，可以肯定的是SOA和微服务的确是一脉相承的，大神Martin Fowler提出来这一概念可以说把SOA的理念继续升华，精进了一步。其核心思想是在应用开发领域，使用一系列微小服务来实现单个应用的方式途径，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署 ，可以是使用不同的编程语言编写。而SOA可能包含的意义更泛一些，更不准确一些。其次，从实现方式上，两者都是中立性，语言无关，协议跨平台，相比SOA，微服务框架将能够带来更大的敏捷性，并为你构建应用提供更轻量级、更高效率的开发。而SOA更适合大型企业中的业务过程编排、应用集成。另外还有微服务甚至是去ESB、去中心化、分布式的，而SOA还是以ESB为核心，大量的WS标准实现。再次，从服务粒度上，既然是微，必然微服务更倡导服务的细粒度，重用组合，甚至是每个操作（或方法）都是独立开发的服务，足够小到不能再进行拆分。而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度，微服务更多为了可扩充性、负载均衡以及提高吞吐量而去分解应用，但同时也引发了打破数据模型以及维护一致性的问题。最后，从部署方式上，这个是最大的不同，对比Monolithic（有人翻译为单体）的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个 全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
SOASOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。当然企业还需要对服务治理，比如服务注册库，监控管理等。我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。微服务而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。这就是我对SOA和微服务架构区别的一点理解。
SOA：面向服务架构，java级企业开发的首选。微服务：采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！SOA我想我就不用细说了，使用java EE开发过的都知道其中的具体流程和步骤，J2EE的确在统一开发中有着很好的使用，但是随着模块功能的不断扩展或者变动，对于其中一点的维护可能会影响到整体的项目。所以有了微服务，彻底的将耦合性再次的降低了。为什么要讲我实习呢，因为微服务的使用会随着单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。 必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。所以自动化运维是十分必要的。总的说来，微服务有以下几个特征：1. 通过服务实现组件化；2. 按业务能力来划分服务与组织团队；3. 服务即产品；4. 智能终端与哑管道；5. 去中心统一化；6. 基础设施自动化；7. Design for failure；8. 进化设计
扫一扫
353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
