互联网架构演变

[](()流动计算架构

====================================================================

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压

力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关

键。

平台随着业务的发展从 Alin One 环境就可以满足业务需求(以 Java 来说，可能只是一两个 war 包就解决

了) :发展到需要拆分多个应用，并且采用 MVC 的方式分离前后端，加快开发效率:在发展到服务越来越

多，不得不将一些核心或共用的服务拆分出来，提供实时流动监控计算等，其实发展到此阶段，如果服务

拆分的足够精细，并且独立运行，这个时候至少可以理解为 SOA ( Service-Oriented Architectyre)-架构 c

了。

[](()服务化

=================================================================

• 服务化的特点

上面介绍的分布式架构即服务化。我们再总结一下，服务化主要有如下特点：

应用按业务拆分成服务

各个服务均可独立部署

服务可被多个应用共享

服务之间可以通信

• 服务化的好处

架构上系统更加清晰

核心模块稳定，以服务组件为单位进行升级，避免了频繁发布带来的风险

开发管理方便

单独团队维护、工作分明，职责清晰

业务复用、代码复用

非常容易拓展

• 服务化实现方式

如果要实现服务化的话，最常用的方式就是利用 RPC 框架。因为服务组件一般分布在不同的服务器上，所以要实现服务化需要解决的第一个问题就是 RPC 远程服务调用。类似于 RPC 方案有很多，比如：

Java RMI

WebService

Hessian

Http

Thrift

… …

• 服务化面临的挑战

上面提到要实现服务化首先需要解决远程服务调用问题，除此之外，还有很多其他问题需要解决。

服务越来越多，配置管理复杂

服务间依赖关系复杂

服务之间的负载均衡

服务的拓展

服务监控

服务降级

服务鉴权

服务上线与下线

服务文档

… …

• 服务治理

上面提到了服务化，其实要想服务化，服务治理是关键。那么有没有好的服务治理方案呢？答案是有的，而且很多人都在用这个框架，他就是-dubbo。dubbo 就是一个带有服务治理功能的 RPC 框架。

dubbo 提供了一套较为完整的服务治理方案，所以企业如果要实现服务化的话，dubbo 是很好的一个选择。这里简单介绍一下 dubbo 服务治理相关方案。

• 服务发现注册

服务治理领域最重要的问题就是服务发现与注册。dubbo 中引入了一个注册中心的概念，服务的注册与发现主要就依赖这个服务中心。

dubbo 注册中心服务注册发现的具体过程：

服务提供者启动，向注册中心注册自己提供的服务

消费者启动，向注册中心订阅自己需要的服务

注册中心返回服务提供者的列表给消费者

消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求

服务监控、集群容错、负载均衡

Random Loadbalance

RoundRobin

LeastActive

ConsistentHash

dubbo 服务治理优势

注册中心只负责注册查找，不负责请求转发，压力小

注册中心宕机影响消费者，消费者本地缓存服务地址列表

注册中心对等集群，宕掉一台自动切换到另外 一台

服务提供者无状态，可动态部署，注册中心负责推送

统计无压力，本地内存中累计次数，每分钟发送注册中心

消费者调用服务者，自动软负载均衡

通过服务中心可追踪依赖关系

监控中心为扩容和降级提供依据

可启用 acl 机制进行鉴权

与 Spring 整合，接入简单松耦合

多种序列化协议支持

dubbo 的不足

消费者仍需要依赖配置中心

消费者仍需要依赖 jar 包配置 provider

提供者文档管理功能缺失

无统一入口

不支持 OAuth2.0

内部鉴权不方便管理

无外部应用鉴权

接口基本裸奔，无法直接对外暴露服务

IT 治理不方便

[](()微服务

=================================================================

现在很多人都在谈微服务，那么到底什么是微服务呢？这里谈谈我对微服务的理解。

微服务有两个核心：