微服务的个人理解与对SOA的比较

微服务的个人理解与对SOA的比较

​　　最近开始学习SpringCloud，绕不过的就是微服务，首先就专门去拜读了马丁福勒对微服务的讲解，之后又到处阅读了牛人们对微服务的理解，最后思考并且整理了一下得到了我自己的一些对微服务的理解。

​　　说到微服务，不少人会拿它和现今最成熟的SOA面向服务架构对比，不少人认为其实微服务也就是SOA，换汤不换药，只不过微服务更强调“微“罢了。

​　　其实这么说也有一定的道理，微服务确实更强调细颗粒的业务划分，微服务的观念认为SOA更像是一个成熟的模块整体和一个成熟的模块整体之间的通信，最后中央式集中调用，而微服务则强调专门的人做专门的事，采用更加细致的划分，几个人甚至一两个人负责完成一个微服务，比如一个购物车模块就是一个微服务，一个订单模块就是一个微服务，微服务与微服务之前是独立部署存在的，而SOA则可能一个服务就包含了购物车，订单，支付等等模块。这就导致了SOA中一个功能例如订单模块出现问题重新Build就会影响其他的服务，而这是微服务不希望看到的。

​　　SOA确实划分更加粗颗粒一些，但是微服务也不仅仅只是强调"微"。它与SOA最大理念的不同在于目前一个基于SOA架构开发的商城，不管服务怎么划分，它们之间都是使用如Spring框架作为主骨架，紧密相连没，并且通过RPC或者web请求进行通信，而微服务则强调耦合到一个极致，它不需要一个主体骨架，它甚至允许你每个模块使用不同的编程语言，使每个模块成为一个单独组件，微服务是Restful风格的，它们最终通过http或者消息连接通信连接成为一个整体。

​　　微服务的优势：极致的耦合使得单个微服务的升级更新换代对其他部分的影响降低，明确的边界更加容易扩展。每个小团队职责更加清晰，单个服务开发更加简单效率，并且可以和不同语言的微服务进行通信。Springcloud微服务框架有非常全面的技术支持，社区活跃度丰富。

​　　微服务的缺点：理想是美好的，现实确实非常残酷，服务虽然确实耦合到了极致，但是也代表分布到了极致，但是不管怎么样拆分变为微服务最终都需要统一的调度，统一的安全权限策略，统一的管理，这施行起来也不容易，对运维来说成本也是非常高昂的，特别是一个大型的项目改变为微服务之后，量变会成为质变，这些微服务的统一调度管理是非常庞大的工作量，而微服务提出的解决策略更加松散分布式的管理，甚至希望一个微服务小团队要伴随它的微服务整个生命周期，但这对公司来说显然不是一个实际并且容易实现的一件事，微服务虽然可以更高效低成本的解决运行时产生的问题和功能的更新换代，但也有可能一开始它就是一个大麻烦。

​　　总结：仅仅是个人理解，总之，对于分布开发来说，SOA还是相当成熟主流的趋势，目前国内传统的大型互联网公司不会大规模使用SpringCloud，因为毕竟它还不够成熟，但是这个理念提出并且受到许多人的追捧一定会有它的意义，国内也有许多中小型公司开始使用甚至直接全面转型SpringCloud，所以说不定以后的SpringCloud就如Spring框架一样成为主流没有之一，我们只有且学且看。