1.2 从服务化到微服务

产生新事物的原因一定是新事物的优越性和旧事物的缺陷两方面导致

背景：服务的用户量逐渐增加、大规模高并发请求

Web Service的问题如下：

• 依赖中心化的服务发现机制
• 使用SOAP通信协议，通常使用XML格式来序列化通信数据，XML格式的数据冗余太大，协议太重
• 服务化管理和治理设施并不完善

ESB的问题如下：

• ESB虽然是SOA实现的一种方式，却更多体现了系统集成的便利性，通过统一的服务总线将服务组合在一起，并提供组合的业务流程服务。
• 组合在ESB上的服务本身可能是一个过重的整体服务，或是传统的JEE服务等。
• ESB视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在
• 对于总线本身的中心化管理模型，系统变更影响的范围经常会随之扩大。

微服务架构：

微服务架构并不是为了拆分而拆分，整整的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业的事，人员和项目的职责单一、低耦合、高内聚，所以产生问题的概率就会降到最小。

微服务的架构图：

从图中可以看出 :

• 微服务把每一个职责单一的功能放在一个独立的服务中。
• 每个服务运行在一个单独的进程中。
• 每个服务有多个实例在运行，每个实例可以运行在容器化的平台内，达到平滑伸缩的效果。
• 每个服务都有自己的储存。
• 每个服务都有自己的运营平台，每个服务都高度自治，内部的变化对外透明。
• 每个服务都可根据性能需求独立地进行水平伸缩。

传统单体架构的伸缩架构：

对比微服务架构与传统单体架构，传统单体架构特点：

• 传统单体架构将所有模块化组件混合后运行在同一个JVM进程中。
• 可对包含多个模块化组件的整体JVM进程进行水平扩展，而无法对某个模块化组件进行水平化扩展。
• 某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线。
• 久而久之，模块间的依赖将会不清晰，相互耦合、相互依赖成为家常便饭。

• 目的不同
  • SOA服务化涉及的范围更广一些，强调不同异构服务之间的写作和契约，强调有效集成、业务流程编排、历史应用集成等。
  • 微服务目的是有效地拆分应用，实现敏捷开发和部署，达到单一微服务更容易水平扩展的目的。
• 部署方式不同
  • SOA服务化通常将多个业务服务通过组件化模块方式打包在一个War包里，然后统一部署在一个应用服务器上。
  • 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的Docker技术来实现自动化的容器管理，每个微服务运行在单一的进程内，微服务中的部署相互独立、互不影响。
• 服务粒度不同
  • SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。
  • 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆分到职责单一，甚至小道不能再进行拆分。