一、微服务架构与SOA服务化的对比
1、目的不同
- SOA服务化涉及的范围更广一些,强调不同的异构服务之间的协作和契约,并强调有效集成、业务流程编排、历史应用集成等,典型代表为Web Service和ESB。
- 微服务使用一系列的微小服务来实现整体的业务流程,目的是有效地拆分应用,实现敏捷开发和部署,在每个微小服务的团队里,减少了跨团队的沟通,让专业的人做专业的事,缩小变更和迭代影响的范围,并达到单一微服务更容易水平扩展的目的。
2、部署方式不同
- 微服务将完整的应用拆分成多个细小的服务,通常使用敏捷扩容、缩容的Docker技术来实现自动化的容器管理,每个微服务运行在单一的进程内,微服务中的部署互相独立、互不影响。
- SOA服务化通常将多个业务服务通过组件化模块方式打包在一个War包里,然后统一部署在一个应用服务器上。
3、服务粒度不同
- 微服务倡导将服务拆分成更细的粒度,通过多个服务组合来实现业务流程的处理,拆分到职责单一,甚至小到不同再进行拆分。
- SOA对粒度没有要求,再实践中服务通常是粗粒度的,强调接口契约的规范化,内部实现可以更粗粒度。
二、服务化管理和治理框架的技术选型
(1) RPC
1、JDKRMI
从JDL1.4开始内置,是JEE规范中EJB远程调用的基础。
缺点:
- 采用JDK自带的专用序列化协议,不能跨语言
- 使用了底层的网络协议,不如基于文本的HTTP刻度,也比如HTTP被广泛认可和应用
- 开源框架的飞速发展,严重削弱了JDK资深技术的流行程度
2、Hessian及Burlap
基于HTTP传输,其中Hessian将对象序列化成语言无关的二进制协议;而Burlap将对象序列化成与语言无关的XML数据,数据是可读的。两者都是与语言无关的,可以在多种语言的服务中互相调用。
Hessian及Burlap都适合传输较小的对象,对较大、复杂的对象,无论是在序列化方式上还是在传输通道上都没有RMI有优势。
由于服务化架构中大量的服务调用都是大规模、高并发的短小请求,因此,Hessian和Burlap协议在服务化架构中得到了广泛应用。
3、Spring HTTP Invoker
重用了JDK内置的对象序列化技术传输对象,与RMI的原理一致,但通过HTTP通道传输数据,在效率上应该略低于RMI,并且由于使用了JDK内置的序列号机制,不能跨语言
(2)服务化
1、Dubbo
支持多种序列化协议和通信编码协议,默认使用Dubbo协议传输Hessian序列化的数据,使用ZooKeeper作为注册中心来注册和发现服务,并通过客户端负载均衡来路由请求,负载均衡算法包括:随机、轮询、最少活跃调用数、一致性哈希等。基于Java语言,不能与其他语言的服务化平台互相调用。
缺点:
没有经过全面优化,在服务量级到达一定程度时,会出现通知系统携带过多的冗余信息,在极端情况下会导致网络广播风暴
Dubbo服务框架是SOA服务化时代的产物,对微服务化提出的各种概念如熔断、限流、服务隔离等没有做精细的设计和实现
Dubbo的监控和服务治理模块比较简单,难以满足复杂业务的需求
2、HSF
为开源,性能比Dubbo高,但是与业务系统耦合重,无法抽取并开源。
3、Thrift
采用中间的接口描述语言定义并创建服务,支持跨语言服务开发和调用,并且包含中间的接口描述语言与代码生成和转换工具,支持包括C++、Java、Python、PHP、Ruby、Erlang、Perl、Haskell、C#、Cocoa、Smalltack等在内的流行语言,传输数据采用二进制序列化格式,相对于JDK本身的序列化、XML和JSON等,尺寸更小,在互联网高并发、海量请求和跨语言的环境下更有优势。如果正在建设跨语言的服务化平台,则Thrift是首选。
4、AXIS
5、Mule ESB
三、微服务技术选型
1、Spring Boot
2、Netflix
3、Spring Cloud Netflix
服务发现组件Eureka
容错性组件Hystrix
智能路由组件Zuul
客户端负载均衡组件Ribbon
四、微服务架构的主要特点
- 将传统单体应用拆分成网络服务,来实现模块化组件
- 根据微服务架构的服务划分来分组职能团队,减少跨团队的沟通
- 每个服务对应一个团队,团队成员负责开发、测试、运维和运营,开发后在团队内运维来运营,不需要交付给其他团队
- 去中心化、去SOA服务化的中心服务治理和去企业服务总线
- 微服务重视服务的合理拆分、分层和构造,可建设自动化持续发布平台,并进行敏捷开发和部署
- 具备兼容性设计、容错性设计和服务的契约设计