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

laputa73

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

sjf0115

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

每个人对微服务都可以有自己的理解，不过大概的标准还是有一些的。

（1）分布式服务组成的系统

（2）按照业务而不是技术来划分组织

（3）做有生命的产品而不是项目

（4）Smart endpoints and dumb pipes

（5）自动化运维

（6）容错

（7）快速演化

看了以上几个方面，相信很多人都会问一个问题，这是不是就是SOA换了个概念，挂羊头卖狗肉。有说法把微服务叫成Lightway SOA。也有很多传统专家说微服务就是SOA。其实微服务创始人Martin也没否认SOA和Microservice的关系。个人理解，微服务是SOA的传承，但一个最本质的区别在Smart endpoints and dumb pipes，或者说是真正的分布式的、去中心化。Smart endpoints and dumb pipes本质就是去ESB，把所有的“思考”逻辑包括路由、消息解析等放在服务内部（Smart endpoints），去掉一个大一统的ESB，服务间轻（dumb pipes）通信，是比SOA更彻底的拆分。

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

随着更多的应用被部署到云平台，人们的挫败感渐增。更新周期被紧紧绑定——即便是应用中一个很小部分的改变，也需要整个应用的重构和部署。随着时间推移，保持一个良好的模块化架构也日益困难，牵一发而动全身。一旦要进行扩展，就必须整体扩展，而不能仅仅扩展其中到一部分模块，也就需要更多的资源

这种情况最后进化为微服务架构：把应用作为一组服务来构建。这些服务能够独立部署和扩展，每个服务提供一个坚实的模型边界，甚至可以用不同的程序语言来写这些服务。当然他们也能被不同的团队来管理。

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

微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。

微服务架构模式应用的改变将会波及多个服务。

部署一个微服务应用也很复杂。