【好书推荐】实践“微服务”，你“玩得起”吗？（获奖名单已公布）

supergirlxu

SOA 与 MSA（微服务架构）区别在于系统一体化与服务组件分散化（“微化”）的区别。服务组件微化可以让关注点进一步缩小范围，服务之间的规范或者实现的关联性进一步降低(https://my.oschina.net/waylau/blog/617857
)。但同时引入的一些问题：
* 服务治理；
* 服务的版本更新；
* 服务之间的权限是如何来做控制的；
* 服务如何来划分颗粒度。
请教下，贵公司在实践过程中，有无遇到过上述问题，是如何解决的？

xiaojun63

微服务，分开来就是微、服务。体现了粒子程度更小，构建业务流程更灵活。就好比restful就行的原理一样

jieforest

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

chenyx

还没接触到微服务呢,搬个板凳坐等讨论

heguangwu

1、你了解微服务吗？SOA和微服务有何差异？
     微服务实质上就是SOA的一种实现方式，SOA是一个失败的项目，所以微服务不想和他扯上关系
     微服务是一种基于服务(Service)的架构，这些Service可独立测试、部署、升级。微服务架构为整个开发周期中提供了灵活的控制
2、到底在什么样的情况才适合使用微服务架构？
     业务清晰并可以被划分成一个个独立的service，service之间不需要复杂的相互调用关系
3、服务与服务之间的事务怎么做?接口的调用权限如何控制,粒度在方法级别的
     服务之间是事务是指分布式事务吗？怎么做取决于这类分布式事务是否很多，如果很少那就例外，如采用在某一个服务来做，如果很多那就可以采用分布式事务的做法，但通常都比较复杂，个人认为得不偿失，还不如考虑这些服务不拆分
4、为什么有人说“玩不起”？较比普通架构需要多做那些工作？
    最主要的性能不好把控，因为微服务是一个分布式架构，运维和问题定位会复杂很多

forgaoqiang

1、你了解微服务吗？SOA和微服务有何差异？最近国内外技术论坛博客上微服务话题非常热门，个人也读过一些文章，对微服务也有些理解。
微服务架构属于应用技术架构，和B/S架构类似。强调的是把复杂的“巨型单应用”拆分成小的应用，数据上也从集中存储拆分为更小的存储单元。
至于SOA是企业架构的范畴，主要是把业务上分解为不同的服务，不同的物理系统提供不同的服务，注重的是系统之间通过服务进行互联交互的规范，对于如何实现这些服务并没有做规定。
因此个人理解是，SOA是更大一些的架构规范，没有规定具体实现，而微服务则是如何实现具体的业务，两者并没有直接关系。完全可以使用SOA实现企业服务，具体的服务则通过微服务的形式进行拆解。



2、到底在什么样的情况才适合使用微服务架构？
①首先，微服务架构的应用肯定是用在较大规模的服务上，规模大指的是业务发杂程度高。
②需要经常进行升级修改的服务，对于多年不需要变化的服务没有必要进行拆分。
③系统越来越庞大，启动速度过慢，无法进行维护。
④不同服务根据实际需求需要采用不同的技术实现（甚至是不同语言实现）的时候。



3、服务与服务之间的事务怎么做?接口的调用权限如何控制,粒度在方法级别的？
为了保证数据的一致性，事务是不可避免要上的，每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。服务之间的通信和Java的ESB不同，微服务应用采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。
每个服务都根据内部处理情况返回结果，服务仍然需要分层，一旦底层服务调用失败，要有对应的异常处理机制。至于权限控制，目前来看不可避免的需要在每次调用的是有带上token凭据，微信公共号开发就是类似的原理，保证权限控制，粒度应该在每次调用都需要进行检查。



4、为什么有人说“玩不起”？较比普通架构需要多做那些工作？

这个的确会增加复杂度，首先整个系统是分布式的，而且数据存储也是分离的，即使根据CAP原理，要保证数据的一致性也会变得更加困难，比如有以下的难题：
①服务因为是分布式的，业务调试难度增加，沟通成本显著增加。
②微服务架构模式应用的改变会波及多个服务，特别是服务之间有依赖的情况，需要协调多服务变更。
③每个服务都有自己的实例，运行状态，需要分别配置、部署、监控，还要实现服务的发现机制，目前视乎不像SOA那样有成熟的服务发现机制。


以前看过一篇文章说明比如构建一个滴滴打车或者Uber一样的应用，提出了传统和微服务的两种架构，感觉不错，的确可以参考：

①这个是传统的单应用架构，核心是业务逻辑

下面是微服务方式实现的，每一个应用功能区都使用微服务完成，另外，Web应用会被拆分成一系列简单的Web应用

chenxing2

1、你了解微服务吗？SOA和微服务有何差异？

    SOA：面向服务的架构，ESB是其一种实现，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
    微服务：是随着互联网的兴起而出现的，互联网主要就是快速迭代，对于SOA这样重的系统，迭代一次是很痛苦的，完全达不到互联网时代的要求，所以将一些独立的服务抽取出来，做一个小型的服务（微服务），方便快速迭代，即使出问题，也不会影响不相关的服务，根据各自服务的特性可以选择最佳的编程语言来实现。

2、到底在什么样的情况才适合使用微服务架构？

    最最合适的情况是，不依赖其他服务而又能对外提供服务，且又不涉及事物问题
   
3、服务与服务之间的事务怎么做?接口的调用权限如何控制,粒度在方法级别的？

服务与服务之间都是独立的，不可能跟传统写法一样，在一个大事物中处理。
传统做法使用 分布式事物XA 两阶段提交，但性能会较差些，一般互联网公司很少使用这种方式
一般使用最终一致，即通过后续补偿保证数据的一致性。
在服务拆分或设计时就要尽量避免这种情况出现。

服务的调用通常不会暴露到公网，都是内网调用，不必限制到方法，通过ssl或ip控制即可
一般接入层涉及访问控制，通常使用spring security或apache shiro来控制资源的访问

4、为什么有人说“玩不起”？较比普通架构需要多做那些工作？

玩不起是因为后期微服务会变得复杂，
要多做的工作：服务注册与发现、熔断恢复、黑白名单、超时控制、服务容错、灰度路由、链路追踪、容量规划、
实时监控、流量控制、服务降级、幂等保障以及分库分表、事物等等

cxsvip

高大上的话题，不了解

Fl_wolf

微服务这东西还真不是很懂 0 0。。 我就来支持楠子一下。。 继续看其他书去了。。

laputa73

正在关注这个问题。
我觉得soa和微服务思路上没有本质区别，主要是领域问题，一个是对外，关注共享， 一个是对内，关注通信。
二者在管理需求上有较大差异。
再就是度的问题，soa开放的接口数量远比微服务小，量变到质变。
微服务和corba其实有点象。