微服务入门

传统业务应用

在没有提出微服务的概念时，一个软件应用，往往会将应用所有功能都开发和打包在一起，运行在通用的服务器上，如Tomcat等。此时，大多数应用都在一个JVM中，随着应用的增大，性能会不断下降；业务之间的耦合严重，即使企业内部有规范和约束，但随着业务逻辑复杂度的增加，开发人员的不断流动，整个应用的维护变得越来越难。

传统应用带来的问题：

• 代码臃肿，应用启动时间长；
• 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
• 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
  例如使用传统业务进行统一部署时，订单模块、用户模块、影院模块各占三分之一的内存。项目上线时，有的模块并发量小，有的模块并发量大，当并发量大的模块需要扩容时，相对复杂。
• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。

微服务发展历程

随着互联网应用规模不断扩展，单体应用架构无法满足需求，分布式应用势在必行。

面向服务开发-SOA

SOA（Service-Oriented Architecture）将单一进程的应用做了拆分，形成独立对外提供服务的组件，每个组件通过网络协议对外提供服务。通过这种协议，服务之间可以通过接口进行交互。通过这种架构，将重复的功能抽取为服务，可以提高开发效率，提高系统的可重用性、减少系统中的接口耦合。

常用的SOA实现方式有两种：Web Service和ESB。Web Service通常使用SOAP协议，即用HTTP和HTTPS来传输XML数据。所有的Web Service服务都会注册到Web Service的目录中，每个服务都依赖于这个目录来发现存在的服务。

ESB简称企业服务总线，服务之间的通信与调用都通过总线来完成，ESB作为项目与服务之间通信的桥梁。

缺点

• 系统与服务的界限模糊，不利于开发及维护。
• 虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
• 取的服务的粒度过大，系统与服务之间耦合性高。

微服务开发

SOA最早的出现是为了解决企业不同系统之间整合的问题，提出服务重用和消息总线。SOA中存在大量的编排，通常通过消息总线来承载业务逻辑，并构建出重量级中心化的中间件。SOA有个很大的问题在于总线，按照这个思想，这些系统总会在某个环节上走向集中，所以去中心化做的很不彻底。

微服务和SOA一脉相承，是一种将业务系统进一步拆分的架构风格。

微服务强调每个单一业务都独立运行，每个单一服务都应该使用更轻量级的机制保持通信。

微服务不强调环境，可以不同语言或数据源，它不关心你用的是Java还是Python，数据库用的是Mysql还是Redis，仅面向自身单一的服务。

特点

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责。
• 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
• 自治：服务间互相独立，互不干扰。每个服务都是一个独立的开发团队。
• 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
• 数据库分离：每个服务都使用自己的数据源
• 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护。

常见分布式系统框架

接入层
CDN：静态资源缓存
LVS：负载均衡
Nginx：负载和反向代理

Openresty
Nginx+Lua的中间件
处理非业务数据 IP黑名单等应用防火墙 在应用之前做拦截等

应用层
微服务框架
服务治理
自动化运维发布

缓存
热点数据 分布式Session

消息队列
异步 解耦 削峰

持久层
MySQL 文件系统

微服务的选择

Dubbo

Dubbo主要基于Netty和Mina构成，提供高性能、透明的RPC调用。Dubbo可以让开发者像调用本地方法一样调用远程服务，而不需要显式在代码中指定是远程调用。整个过程对开发者透明，Dubbo会自动完成后续的所有操作，例如：负载均衡、路由、协议转换、序列化等。开发者只需要接收对应的调用结果即可。

Dubbo提供了注册中心机制，解耦了消费方和服务方动态发现的问题，并提供高可靠能力，大量采用微内核+富插件设计思想，包括框架自身核心都作为扩展点实现，提供灵活地可扩展能力。

服务提供者在启动时会向注册中心注册自己的元数据（服务IP和端口等），服务消费方在启动时从注册中心订阅服务提供方的元数据，注册中心发生数据变更会推送给订阅的消费者。在获取服务元数据后，服务消费方可以发起RPC调用，在RPC调用前后会向监控中心上报统计信息。

SpringCloud

微服务全家桶

Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 – 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。

Dubbo类似于Spring Cloud的一个子集，Dubbo功能和文档完善，在国内有很多的成熟用户。Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。Dubbo架构下，注册中心对等集群，并会缓存服务列表，当服务下线时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。

Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。
对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。

Zero ICE

二进制流

Dubbo

Dubbo总体分为业务层、RPC层、Remote层。Dubbo框架中的分层代表了不同的逻辑实现，他们是一个个组件，这些组件构成了整个Dubbo体系。