授课视频在线视频

嗨，大家好

今天我们来讨论微服务架构

首先我们从Dubbo说起

Dubbo是Alibaba推出的一款开源的

高性能分布式服务框架

它致力于提供高性能和透明化的

RPC远程服务调用方案

以及SOA服务治理方案

Dubbo可以和 Spring系统无缝集成

Dubbo最大的特点是按照分层的方式来架构

它将整个框架分成10层

来为服务提供方和服务消费方

提供各自需要关心和扩展的接口

来构建整个服务生态系统

我们通过Dubbo的架构蓝图来看一看

一个网站系统架构的变化

当这个网站流量很小的时候呢

只需要一个应用就可以将所有的功能都部署在一
起

这样可以减少部署节点和成本

这个时候，用于简化增删改查工作量的

数据访问框架，也就是我们说的ORM，这是是关
键

当访问量逐渐增大的时候

单一应用通过增加机器带来的加速度越来越小

我们可以将应用拆成互不相干的几个应用

以提高它的效率

这个时候呢，用于加速前端页面开发的

这种Web框架，也就是MVC，是关键

当这种垂直应用越来越多

应用之间的交互变的不可避免

我们可以将核心的业务抽取出来

作为独立的服务，逐渐形成稳定的服务中心

使前端应用能更快速的响应多变的市场需求

这个时候，用于提高业务复用及整合的

分布式服务框架，也就是RPC，是关键

当服务越来越多，容量的评估

小服务资源的浪费等等问题逐渐显露出来的时候

就需要增加一个调度中心

基于访问压力来实时的管理集群容量

提高集群的利用率

这个时候，用于提高机器利用率的资源调度

和治理中心，也就是SOA，是关键

那么，当业务的复杂性进一步增加的时候

我们可以采用什么样的架构呢

从前面的roadmap大家也看出来了

无论是单一应用还是MVC应用

都是一种应用的层面，不涉及服务的概念

从RPC到SOA，都出现了服务的概念

那我们就先说说服务吧

首先来了解一下，什么是RPC，为什么要用RPC

RPC是指远程的过程调用

也就是说两台服务器A和B

一个应用部署在A服务器上

它想要调用B服务器上的应用所提供的函数或方
法

由于它们不在一个内存空间，不能直接调用

就需要通过网络来表达

这种调用的语义和传达要调用的参数

RPC首先需要解决的是通讯问题

它的方法是通过在客户端和服务器之间

建立TCP连接

远程过程调用的所有交换的数据

都是在这个连接里面进行传输

连接可以是按需连接，调用结束后就断掉

也可以是长连接

多个远程过程调用来共享同一个连接

第二，要解决寻址的问题

也就是说，A服务器上的应用

怎么来告诉底层的RPC框架

如何连接到B服务器以及特定的端口

方法的名称是什么，这样才能够完成调用

比如基于Web服务协议栈的RPC

就要提供一个endpoint URI

或者是从UDDI的服务上来查找

如果是RMI调用的话，还需要一个RMI Registry

来注册这种服务的地址

当A服务器上的应用发起远程过程调用的时候

方法的参数就需要通过底层的网络协议

来传递到B服务器

我们知道，由于网络协议是基于二进制的

内存中的参数要进行序列化，转化成二进制的形
式

这种转变我们叫序列化

B服务器收到请求之后，需要对参数进行反序列
化

恢复为内存中的表达形式

然后找到对应的方法进行本地调用

得到返回值

返回值也要通过序列化和反序列化的过程

到达A服务器上的应用

实现RPC的协议有很多

比如最早的CORBA，Java RMI

Web Service的RPC风格，Hessian，Thrift

甚至Rest API

那么SOA呢？

它是一个面向服务的体系结构模型

它将应用程序的不同功能单元，我们叫服务

通过这些服务之间定义良好的接口和契约联系起
来

接口是采用中立的方式进行定义的

它应该独立于实现服务的硬件平台

操作系统和编程语言

这使得构建在各种系统中的服务

可以以一种统一的和通用的方式进行交互

SOA的架构当中有三种角色

一是服务提供者，也就是发布自己的服务

并且对服务的请求进行响应

二是服务注册中心

它负责注册已经发布的web服务

对它们进行分类，并提供搜索服务

三是服务的请求者

利用服务中心来查找所需要的服务

然后使用这个服务

SOA的架构提供三种操作

一是发布操作

为了使服务可访问

需要发布服务的描述以使服务的使用者能够发现
它

二是查找操作

服务的请求者来定位服务

它的方法是查询服务注册中心

来找到满足它的标准的服务

三是绑定操作

在检索到服务描述之后

服务的使用者继续根据服务描述当中的信息

来调用服务

SOA需要使用三种协议

一是SOAP，就是简单对象访问协议

二是WSDL，就是 Web服务描述语言

三是UDDI，它是统一描述、发现和集成的缩写

其中，WSDL用来描述服务

UDDI用来注册和查找服务

而SOAP作为传输层

用来在消费者和服务提供者之间传递消息

一个消费者在UDDI注册表中查找服务

取得服务的WSDL描述

然后通过SOAP来调用这个服务

SOA的提出是在企业计算领域将紧耦合的系统

划分为面向服务的，粗粒度的，松耦合

无状态的服务

SOA旨在将单个应用程序功能彼此分开

以便这些功能可以单独作为单个的应用程序

的功能或组件

这些组件可以用于企业内部创建各种各样的

其他的应用程序

或者如果有需要呢，就对外向合作伙伴公开

可以将服务用于合作伙伴的应用程序

企业服务总线ESB是从SOA发展而来的

它是传统的中间件技术与XML、Web服务等技术

结合的产物

ESB提供了网络中最基本的连接中枢

是构建企业神经系统的必要元素

ESB采用了总线这样一种模式

来管理和简化应用之间的集成拓扑结构

以广为接受的开放标准为作为基础

来支持应用之间在消息、事件和服务级别上

动态的互连互通

是一种在松散耦合的服务和应用之间标准的集成
方式

微服务架构强调的一个重点就是

业务系统需要彻底的组件化和服务化

原有的单个业务系统会拆分为多个

可以独立开发，设计，运行和维护的小应用

这些小应用之间通过服务完成交互和集成

每个小应用从前端UI，到控制层，逻辑层

数据访问，数据库都完全是独立的一套

在这里我们不用组件而是用小应用

在这里我们不用组件而是用小应用

这个词更加合适

每个小应用除了完成自身本身的业务功能之外

重点就是还需要消费外部其它应用所暴露的服务

同时也将自己的能力向外发布成为服务

在微服务架构中，一组服务构成一个应用

服务独立地部署在不同的进程中

同服务之间通过一些轻量级的交互机制来通信

像RPC和HTTP等等

服务可以独立扩展和伸缩

每个服务定义了明确的边界

不同的服务甚至可以采用不同的编程语言来实现

由独立的团队来维护

在微服务中，应用被拆散为一系列的服务

运行在不同的进程中，单个服务的变化

只需重新部署对应的服务进程

不影响整个应用的运行

微服务架构将应用按照业务功能

划分为不同的服务

每个服务都要求在对应业务领域当中

从前端到后端的整个的软件实现

从界面到数据库存储，再到外部沟通协作等等

所以微服务是按照业务能力

来划分服务与组织团队的

微服务需要Devops

也就是开发测试和部署运维的一体化的支持

这是因为当我们的单体应用被拆分为

多个小应用之后

虽然整体架构可以松耦合和可扩展

但是如果拆分的组件越多

这些组件之间本身的集成和部署运维就越复杂

这个时候只有强化DevOps的应用

才能更好的完成测试和部署

由于微服务架构里面强调了单个组件本身

是可以在独立的进程里面运行

各个组件之间在部署的时候就能够做到

进程级别的隔离

虚拟机技术无法满足大量的进程隔离的时候呢

就可以用轻量级的Docker来完成

就可以用轻量级的Docker来完成

每个Docker是独立的容器，刚好又完全做到了

进程级别的隔离，资源的占用率又最小

这些特点刚好满足微服务架构的

开发测试和自动化部署

如果所有暴露的微服务需要一个

服务管控和治理平台

我们虽然不需要使用ESB这么重的总线

但是还要保留最基本的服务注册，服务代理

服务发布，简单的路由，安全访问和授权

服务发布，简单的路由，安全访问和授权

服务调用消息和日志记录这些功能

服务调用消息和日志记录这些功能

这就是一个简化版的SOA

作为微架构下的服务管控平台

微服务架构模式有很多好处

首先，通过分解巨大的单体式应用

为多个服务的方法解决了复杂性问题

在功能不变的情况下

应用被分解为多个可管理的分支或服务

每个服务都有一个用RPC

或者消息驱动API定义清楚的边界

微服务架构模式给采用单体式编码方式

很难实现的功能提供了一个模块化的解决方案

由此，单个服务就很容易开发、理解和维护了

第二，这种架构使得每个服务都可以

由专门的开发团队来开发

开发者可以自由地选择开发技术来提供API服务

这种自由意味着开发人员不需要被迫来使用

某个项目开始的时候使用的那种过时的技术

他们可以使用当下的技术

同时，因为服务都相对简单

即便他们用现在的技术来重写以前的代码

也不是一件很困难的事情

第三，微服务架构模式当中每个微服务独立部署

开发者不再需要协调其它的服务部署

对本服务的影响

这种改变可以加快部署的速度

UI团队可以采用AB测试，快速的部署变化

微服务架构模式使得持续化的部署成为可能

最后，微服务架构模式使得每个服务独立扩展

开发者可以根据每个服务的规模来部署满足需求
的规模

开发者可以根据每个服务的规模来部署满足需求
的规模

进一步的，开发者可以使用更适合于

服务资源需求的硬件

《人月神话》当中提到：没有银弹

意思就是只靠一把锤子是不能盖起摩天大楼的

要根据业务场景选择设计思路和实现工具

应用微服务架构的时机应该如何把握呢?

对于业务还没有理清楚、业务数据和处理能力

对于业务还没有理清楚、业务数据和处理能力

还没有开始爆发式增长之前的创业公司

不需要考虑微服务架构模式

这时候最重要的是快速开发、快速部署、快速试
错

微服务强调了服务的大小

有一些开发者也建议建立稍微大一些的服务

尽管的小服务更乐于被采用

但是不要忘了这不是最终的目的

但是不要忘了这不是最终的目的

微服务的目的是有效的拆分应用

来实现敏捷开发和部署

另外一个主要的不足是什么呢？

微服务应用是分布式系统

由此会带来固有的复杂性

开发者需要在RPC或者消息传递之间选择

并完成进程间的通讯机制

相对于单体式应用中通过语言级的

方法或者事进程内调用

微服务下的这种技术就显得更复杂

另外一个关于微服务的挑战就是关于

分区的数据库架构

在微服务架构的应用当中

需要更新不同的服务所使用的不同的数据库

测试一个基于微服务架构的应用也是一个很复杂
的任务

另外还有一个挑战就在于

微服务架构模式应用的改变将会波及多个服务

部署一个微服务应用也很复杂

一个微服务应用一般是由大批服务构成的

每个服务都有多个实例

这就造成许多需要配置、部署、扩展和监控的部
分

传统的解决问题的办法不能解决这么复杂的问题

最后，让我看一下微服务和SOA的简单比较

微服务不再强调传统SOA架构里面比较重的

ESB企业服务总线

同时将SOA的思想加入到

到单个业务系统内部实现真正的组件化

微服务与SOA有很多相同之处

两者都属于典型的、包含松耦合分布式组件的系
统结构

但是两种架构背后的意图是不同的

SOA尝试将应用集成

一般采用中央管理模式来确保各个应用能够交互
运作

微服务尝试部署新功能

快速有效地扩展开发团队

它着重于分散管理、代码再利用与自动化执行

微服务相比于SOA更加精细

微服务更多的是以独立进程的方式存在的

服务之间没有影响

微服务提供的接口方式更加通用化

例如HTTP RESTful方式

各种终端都可以调用

无关语言、平台的限制

微服务更倾向于分布式去中心化的部署方式

在互联网业务的场景下更加适用

我们可以把微服务当做是去除了ESB的SOA

ESB是SOA架构中的中心总线

而微服务则是去中心化的分布式软件架构

好，这部分就讨论到这里，谢谢大家