转载自 点击打开链接
微服务正在领导了一波潮流,那么微服务作为新的理念和SOA(Service Oriented Ambiguity 面向服务架构)有什么区别呢?
相同点:
- 需要实现服务注册发现机制;
- 需要考虑分布式下的事务一致性。CAP原则下,常用手段 两段式提交(不能保证性能),消息驱动(需要事务补偿机制);
- 同步调用还是异步消息驱动;
- 都需要统一的Gateway来汇聚、编排接口,实现统一认证机制,对外提供APP使用的RESTful接口;
- 同样的要关注如何再分布式下定位系统问题,如何做日志跟踪;
那么差别在哪?
- 使用不同的通讯协议是不是区别?微服务的标杆通讯协议是RESTful,而传统的SOA一般是SOAP,不过目前来说采用轻量级的RPC框架Dubbo、Thrift、gRPC非常多,在Spring Cloud中也有Feign框架将标准RESTful转为代码的API这种仿RPC的行为,这些通讯协议不应该是区分微服务架构和SOA的核心差别;
- 是流行的基于容器框架还是虚拟机为主?Docker和虚拟机还是物理机都是架构实现的一种方式,不是核心区别;
微服务架构的精髓在切分
- 服务的切分上有比较大的区别,SOA原本是以一种“集成”技术出现的,很多技术方案是将原有企业内部服务封装为一个独立进程,这样新的业务开发就可重用这些服务,这些服务很可能是类似供应链、CRM这样的非常大的颗粒;而微服务这个“微”,就说明了他在切分上有讲究,不妥协。无数的案例证明,如果你的切分是错误的,那么你得不到微服务承诺的“低耦合、升级不影响、可靠性高”之类的优势,而会比使用Monolithic有更多的麻烦。
不拆分存储的微服务是伪服务:在实践中,我们常常见到一种架构,后端存储是全部和在一个数据库中,仅仅把前端的业务逻辑拆分到不同的服务进程中,本质上和一个Monolithic一样,只是把模块之间的进程内调用改为进程间调用,这种切分不可取,违反了分布式第一原则,模块耦合没有解决,性能却受到了影响。
分布式设计第一原则 – “不要分布你的对象”
微服务的“Micro”这个词并不是越小越好,而是相对SOA那种粗粒度的服务,我们需要更小更合适的粒度,这种Micro不是无限制的小。
如果我们将两路(同步)通信与小/微服务结合使用,并根据比如“1个类=1个服务”的原则,那么我们实际上回到了使用Corba、J2EE和分布式对象的20世纪90年代。遗憾的是,新生代的开发人员没有使用分布式对象的经验,因此也就没有认识到这个主意多么糟糕,他们正试图重复历史,只是这次使用了新技术,比如用HTTP取代了RMI或IIOP。