面试都在问的微服务、服务治理、RPC、下一代微服务... 一文带你完全搞懂！

文章每周持续更新，原创不易，「三连」让更多人看到是对我最大的确定。能够微信搜索公众号「 后端技术学堂 」第一时间阅读（通常比博客早更新一到两篇）

单体式应用程序

与微服务相对的另外一个概念是传统的单体式应用程序( Monolithic application )，单体式应用内部包含了全部须要的服务。并且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。

说在作的各位都写过单体程序，你们都没意见吧？给你们举个栗子，刚开始写代码你写的helloworld程序就是单体程序，一个程序包含全部功能，虽然helloworld功能很简单。

单体应用程序的优势

• 开发简洁，功能都在单个程序内部，便于软件设计和开发规划。
• 容易部署，程序单一不存在分布式集群的复杂部署环境，下降了部署难度。
• 容易测试，没有各类复杂的服务调用关系，都是内部调用方便测试。

单体应用程序的缺点

单体程序的缺点一开始不是特别明显，项目刚开始需求少，业务逻辑简单，写代码一时爽，一直爽。噩梦从业务迭代更新，系统日益庞大开始，前期的爽没有了，取而代之的是软件维护和迭代更新的无尽痛苦。

因为单体式应用程序就像一个大型容器同样，里面放置了许多服务，且他们都是密不可分的，这致使应用程序在扩展时必须以「应用程序」为单位。

当里面有个业务模块负载太高时，并不可以单独扩展该服务，必须扩展整个应用程序（就是这么霸道），这可能致使额外的资源浪费。

此外，单体式应用程序因为服务之间的紧密度、相依性太高，这将致使测试、升级有所困难，且开发曲线有可能会在后期大幅度地上升，令开发不易。相较之下「微服务架构」可以解决这个问题。

微服务

微服务 (Microservices) 就是一些协同工做小而自治的服务。

2014年， Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，本身拥有本身的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其余服务使用 HTTP API 通讯。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务能够用不一样的编程语言与数据库等组件实现 。「维基百科」

举例

仍是拿前面的 helloworld 程序来举栗子，想象一下你是 helloworld 公司的 CTO（老板还缺人吗？会写代码的那种），假设大家公司的 helloworld 业务遍及全球，须要编写不一样语种的 helloworld 版本，分别输出英语、日语、法语、俄语...如今世界有6000多种语言（奇怪的知识又增长了）。

有人会说这还不简单我用switch case语句就完事了，同窗，不要较真我就是举个例子，现实中的业务比 helloworld 复杂多了。好了，咱们姑且认为按语言输出是个庞大复杂的工做，这时候就能够用微服务架构了，架构图以下：

微服务与SOA

面向服务的体系结构 SOA (Service-Oriented Architecture) 听起来和微服务很像，但 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，好比：J2EE。这致使不少企业的遗留系统很难对接，切换时间太长，成本过高，新系统稳定性的收敛也须要一些时间，最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

此外，实施SOA时会遇到不少问题，好比通讯协议（例如SOAP)的选择、第三方中间件如何选择、服务粒度如何肯定等，目前也存在一些关于如何划分系统的指导性原则，但其中有不少都是错误的。SOA并无告诉你如何划分单体应用成微服务，因此在实施SOA时会遇到不少问题。

这些问题再微服务框架中获得很好的解决，你能够认为微服务架构是SOA的一种特定方法。

微服务架构

合久必分，鉴于「单体应用程序」有上述的缺点，单个应用程序被划分红各类小的、互相链接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构。

微服务优势

相对于单体服务，微服务有不少优势，这里列举几个主要的好处

技术异构性

不一样服务内部的开发技术能够不一致，你能够用java来开发helloworld服务A，用golang来开发helloworld服务B，你们不再用为哪一种语言是世界上最好的语言而争论不休。

为不一样的服务选择最适合该服务的技术，系统中不一样部分也可使用不一样的存储技术，好比A服务能够选择redis存储，B服务你能够选择用MySQL存储，这都是容许的，你的服务你作主。

隔离性

一个服务不可用不会致使另外一个服务也瘫痪，由于各个服务是相互独立和自治的系统。这在单体应用程序中是作不到的，单体应用程序中某个模块瘫痪，必将致使整个系统不可用，固然，单体程序也能够在不一样机器上部署一样的程序来实现备份，不过，一样存在上面说的资源浪费问题。

可扩展性

庞大的单体服务若是出现性能瓶颈只能对软件总体进行扩展，可能真正影响性能的只是其中一个很小的模块，咱们也不得不付出升级整个应用的代价。这在微服务架构中获得了改善，你能够只对那些影响性能的服务作扩展升级，这样对症下药的效果是很好的。

简化部署

若是你的服务是一个超大的单体服务，有几百万行代码，即便修改了几行代码也要从新编译整个应用，这显然是很是繁琐的，并且软件变动带来的不肯定性很是高，软件部署的影响也很是大。在微服务架构中，各个服务的部署是独立的，若是真出了问题也只是影响单个服务，能够快速回滚版本解决。

易优化

微服务架构中单个服务的代码量不会很大，这样当你须要重构或者优化这部分服务的时候，就会容易不少，毕竟，代码量越少意味着代码改动带来的影响越可控。

微服务缺点

咱们上面一直在强调微服务的好处，可是，微服务架构不是万能的，并不能解决全部问题，其实这也是微服务把单体应用拆分红不少小的分布式服务致使的，所谓人多手杂，服务多起来管理的很差各类问题就来了。

为了解决微服务的缺点，前辈们提出了下面这些概念。

服务注册与发现

微服务之间相互调用完成总体业务功能，如何在众多微服务中找到正确的目标服务地址，这就是所谓「服务发现」功能。

经常使用的作法是服务提供方启动的时候把本身的地址上报给「服务注册中心」，这就是「服务注册」。服务调用方「订阅」服务变动「通知」，动态的接收服务注册中心推送的服务地址列表，之后想找哪一个服务直接发给他就能够。

服务监控

单体程序的监控运维还好说，大型微服务架构的服务运维是一大挑战。服务运维人员须要实时的掌握服务运行中的各类状态，最好有个控制面板能看到服务的内存使用率、调用次数、健康情况等信息。

这就须要咱们有一套完备的服务监控体系，包括拓扑关系、监控（Metrics）、日志监控（Logging）、调用追踪（Trace）、告警通知、健康检查等，防患于未然。

服务容错

任何服务都不能保证100%不出问题，生产环境复杂多变，服务运行过程当中不可避免的发生各类故障（宕机、过载等等），工程师可以作的是在故障发生时尽量下降影响范围、尽快恢复正常服务。

程序员为此避免被祭天，须要引入「熔断、隔离、限流和降级、超时机制」等「服务容错」机制来保证服务持续可用性。

服务安全

有些服务的敏感数据存在安全问题，「服务安全」就是对敏感服务采用安全鉴权机制，对服务的访问须要进行相应的身份验证和受权，防止数据泄露的风险，安全是一个长久的话题，在微服务中也有不少工做要作。

服务治理

说到「治理」通常都是有问题才须要治理，咱们日常说环境治理、污染治理一个意思，微服务架构中的微服务愈来愈多，上面说的那些问题就更加显现，为了解决上面微服务架构缺陷「服务治理」就出现了。

微服务的那些问题都要公司技术团队本身解决的话，若是不是大型公司有成熟的技术团队，估计会很头大。幸亏，有巨人的肩膀能够借给咱们站上去，经过引入「微服务框架」来帮助咱们完成服务治理。

微服务框架

介绍一些业界比较成熟的微服务框架。

Dubbo

是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可经过高性能的 RPC 实现服务的输出和输入功能，能够和 Spring框架无缝集成。 Apache Dubbo |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现 。2011 年底对外开源，仅支持 Java 语言。

官网： http://dubbo.apache.org/zh-cn/

Tars

腾讯内部使用的微服务架构 TAF（Total Application Framework）多年的实践成果总结而成的开源项目。 仅支持 C++ 语言，目前在腾讯内部应用也很是普遍。2017 年对外开源，仅支持 C++ 语言。

源码： https://github.com/TarsCloud/Tars/

本命鹅厂 TARS 框架介绍 PPT 已下载，不想本身麻烦去找的同窗，在我公众号「后端技术学堂」回复「tars」获取。

Motan

是新浪微博开源的一个Java 框架。Motan 在微博平台中已经普遍应用，天天为数百个服务完成近千亿次的调用。于 2016 年对外开源，仅支持 Java 语言。

官方指南： https://github.com/weibocom/motan/wiki/zh_userguide

gRPC

是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发。自己它不是分布式的，因此要实现上面的框架的功能须要进一步的开发。2015 年对外开源的跨语言 RPC 框架，支持多种语言。

中文教程： https://doc.oschina.net/grpc?t=58008

thrift

最初是由 Facebook 开发的内部系统跨语言的高性能 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一， 跟 gRPC 同样，Thrift 也有一套本身的接口定义语言 IDL，能够经过代码生成器，生成各类编程语言的 Client 端和 Server 端的 SDK 代码，支持多种语言。

微服务框架和RPC

不少人对这两个概念有点混淆，微服务框架上面咱们说过了，咱们再来看下RPC的概念。

什么是RPC

RPC (Remote Procedure Call)远程过程调用是一个计算机通讯协议。咱们通常的程序调用是本地程序内部的调用，RPC容许你像调用本地函数同样去调用另外一个程序的函数，这中间会涉及网络通讯和进程间通讯，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个经过发送请求-接受回应进行信息交互的系统。

二者关系

RPC和微服务框架的关系个人理解，微服务框架通常都包含了RPC的实现和一系列「服务治理」能力，是一套软件开发框架。咱们能够基于这个框架之上实现本身的微服务，方便的利用微服务框架提供的「服务治理」能力和RPC能力，因此微服务框架也被有些人称做RPC框架。

下一代微服务架构

Service Mesh（服务网格）被认为是下一代微服务架构，Service Mesh并无给咱们带来新的功能，它是用于解决其余工具已经解决过的服务网络调用、限流、熔断和监控等问题，只不过此次是在Cloud Native 的 kubernetes 环境下的实现。

特色

Service Mesh 有以下几个特色：

• 应用程序间通信的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

目前两款流行的 Service Mesh 开源软件 [Istio](https://istio.io/) 和 [Linkerd](https://linkerd.io/) 均可以直接在 kubernetes 中集成，其中 Linkerd 已经成为云原生计算基金会 CNCF (Cloud Native Computing Foundation) 成员。

Why Service Mesh

为何现有微服务架构已经解决的问题还要用Service Mesh呢？这个问题问的好。

回答问题以前，先看下istio.io上对service mesh的解释，我以为挺好的，摘抄出来：

As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code.

试着总结一下：随着微服务的增多复杂程度也增长，管理变得更加困难，微服务架构虽然解决了「网络调用、限流、熔断和监控」等问题，但大多数框架和开源软件对原有业务是侵入式的，也就是须要在业务服务程序中集成相关的「服务治理」组件。

Service Mesh之于微服务，就像TCP/IP之于互联网，TCP/IP为网络通讯提供了面向链接的、可靠的、基于字节流的基础通讯功能，你再也不须要关心底层的重传、校验、流量控制、拥塞控制。

用了Service Mesh你也没必要去操心「服务治理」的细节，不须要对服务作特殊的改造，全部业务以外的功能都由Service Mesh帮你去作了。它就像一个轻量级网络代理 对应用程序来讲是透明，全部应用程序间的流量都会经过它，因此对应用程序流量的控制均可以在 serivce mesh 中实现 。

写在最后

在IT世界没有什么技术是永不过期的，微服务架构的演进就是一个例子，从单体程序到微服务架构，再到service mesh架构，我不知道下一个技术迭代点是何时，但我知道微服务架构确定还会更新，IT人更应该创建终身学习习惯。
固然更重要的是拥有对技术的热情，热于拥抱变化、接受新技术，当我看到新技术我是兴奋的，心里os是厉害了，还能这么玩！，但愿你也有这般热情，而不只仅是面向工资编程，生活会有趣不少。
老规矩。感谢各位的阅读，文章的目的是分享对知识的理解，技术类文章我都会反复求证以求最大程度保证准确性，若文中出现明显纰漏也欢迎指出，咱们一块儿在探讨中学习。

原创不易，看到这里动动手指，各位的「三连」是对我持续创做的最大支持，咱们下篇文章再见。

能够微信搜索公众号「 后端技术学堂 」回复「资料」「1024」有我给你准备的各类编程学习资料。文章每周持续更新，咱们下期见！

reference

https://www.cnblogs.com/Zacha...

https://www.zhihu.com/questio...

http://dockone.io/article/3687

https://www.infoq.cn/article/...

https://segmentfault.com/a/11...

https://book.douban.com/subje...

https://jimmysong.io/blog/wha...

https://github.com/weibocom/m...