一、微服务架构与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服务化的中心服务治理和去企业服务总线
• 微服务重视服务的合理拆分、分层和构造，可建设自动化持续发布平台，并进行敏捷开发和部署
• 具备兼容性设计、容错性设计和服务的契约设计