基于微服务论文题目

分布式微服务治理的核心在于: 微服务和分布式

Remote Procedure Call，翻译过来应该是“远程程序调用”，目前业内通用的翻译是“远程过程调用”，但是“过程”这个词很容易造成误解，翻译成“程序”更好理解RPC的意义。

一般所谓的XX协议就是个文档，类似于我们的需求文档，只说了要做什么，但是具体怎么做是由各大开源大佬做的。 一般情况下都会实现核心功能，不同的开源在细节上实现都会不一样，这个需要注意！

RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出的，在 Nelson 的论文 "Implementing Remote Procedure Calls" 中，他提到了几个 RPC的特点 ：

除此之外，这位大佬还给出了实现RPC框架的 详细架构图 ：

结合上图，Nelson 的论文中指出实现 RPC 的程序包括 5 个部分：

所以这架构图的意思是：当 user 想发起一个远程调用时，它实际是通过本地调用 User-stub。并通过本地的RPCRuntime传输 。远端 RPCRuntime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，调用结果再返回给 User 端。

看完协议内容，跟着就得实现这个协议啦，这时候你是不是发现了问题的严重性： 自！己！一！点！思！路！都！没！有！

所以我们需要再理解一下RPC协议，根据Nelson的论文知道我们要做的两件事：

上述两点其实是实现RPC协议的两大要素： 序列化协议和传输协议 。

因为RPC本质上是进程间通信，而“本地调用和远程调用的对比”实际上就是“进程内通信和进程间通信的对比”。通过两者的对比，我们才能理解到 序列化协议和传输协议 的作用，如下图：

最基本的RPC框架就是 单点式 的，因为A服务直接调用B服务，不经过第三方，这种是最简单的。但是必须是A和B同时部署一套，A1只能调用B1，A2只能调用B2。

所以需要一台A服务对多台B服务，利用第三方服务(注册中心)找到其他B服务，而不是写死B服务的地址。这种RPC才是 分布式 RPC，也是业内主流。

单点RPC框架只需要：

但是我们要做分布式的啊，所以需要：

实际上在生产环境中，我们需要实时监控服务的调用情况，所以需要一个微服务管理中心，甚至是一个自动化运维的管理中心，所以需要：

在文章的第二节我们看到大佬论文中对RPC的总结，其中一个很重要的一点：“通用”。

所以我们需要：

对的，能实现上述五点的，才是一个合格的RPC框架，但还不是优秀，因为我们还要考虑下性能。

先打个底，目前流行的RPC框架大多都是多管闲事，不单单只是RPC框架，你可以看看Dubbo和SpringCloud中除了RPC还有什么骚功能。

可以看看别人的各种RPC框架总结： 在网上找到了个图，但是没有提到SpringCloud，暂且看看先，因为有些不认为是对的：

我们可以看到各个RPC框架使用的序列化协议，注册中心，管理中心，是否跨语言，但是传输协议没有提到。

参考这篇博客： 综合来说，在性能上rpcx是首选，但是考虑到框架的生态，其实还是推荐Dubbo或者SpringCloud的，因为除了性能，成本也是很重要的，无论是学习成本还是研发成本。

在传统的单应用架构下，接口的日志监控还是非常简单的，但是随着分布式、微服务架构的兴起，我们会面对更为复杂的服务交互关系； 也就是说，以往的系统，更多的是A系统调用B系统，而现在可能面对这A->B->C->D，而在这种情况下，如果没有链路跟踪的方案，那么查找和定位问题就会非常困难。理论基础 Google公司研发了Dapper分布式跟踪系统，并发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》； 目前行业内大部分的分布式跟踪方案都是基于这篇论文来实现的；这篇论文中提到了几个比较重要的概念：A：parentId=null、spanId=1； B：parentId=1、spanId=2； C：parentId=2、spanId=3； D：parentId=2、spanId=4；实现方案 我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。 集成zipkin或者spring cloud sleuth都可以的

微服务

维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

微服务概念的由来是怎么样的呢，参考维基百科英文版，简单梳理后的微服务出现的 历史 ：

顺便说一句，这几个人都是大名鼎鼎的，名字可能陌生，但是摆出他们的作品，相信多少是有些了解的。 Martin Flower是《重构》、《UML 精粹》的作者；Robert Martin，人称 Bob 大叔，敏捷专家，《代码整洁之道》、《架构整洁之道》的作者。 既然微服务是SOA架构的一种变体，那么，谈微服务，SOA就是一个跨不过去的一个话题。

SOA

SOA的全称是“Service Oriented Architecture”，中文翻译是“面向服务架构”，1996年，由Gartner公司最早提出SOA概念。它的诞生是有其 历史 背景的。

同时，基于这样的背景，Gartner公司提出了SOA的概念，并且还给了一个预言，它预言在2008年，SOA会成为一种最流行的、且占有绝对优势的软件工程实践办法。

很多时候，我们认为SOA已经消失在江湖，实际上并非如此，许多传统行业，比如物流、仓储行业的系统都是采用SOA架构来构建的。

对于SOA，从图中可以看到，它的每一项业务功能都是一个服务，都需要对外提供服务的能力，来完成企业所需的各项业务功能，也就意味着它具有对外提供开放的能力，这些能力无需定制化就可以实现。为什么无需定制化呢，核心就在于ESB。

看到ESB的功能，是不是觉得它的功能有点似曾相识？是的，它就是微服务所需要的基础服务。

简而言之，微服务架构风格 ，是一种 将单个应用程序开发为一组小服务 的方法，每个小服务都 在自己的进程中运行并与轻量级机制（通常是 HTTP 资源 API）进行通信 。 这些服务是围绕业务能力构建的，并且 可以通过全自动部署机制独立部署 。 这些服务的集中管理最少，可以用不同的编程语言编写并使用不同的数据存储技术。

上面一段话是Martin Fowler关于微服务架构论文中的核心片段，从上述片段中，我们提炼出微服务架构的核心有三点：

其一是“ 小服务 ”，将应用拆分为一组小服务；

其二是“ 在自己的进程中运行并与轻量级机制（通常是 HTTP 资源 API）进行通信 ”，微服务是由独立进程且进程之间通过轻量级机制进行通信；

其三是“ 可以通过全自动部署机制独立部署 ”，也就是说每个微服务可以快速独立部署。

其实这已经非常精确、精准的描述出了微服务的基本特征。完全可以作为在微服务架构实践中落地的三个参考依据与检验标准。

对比维度

微服务

SOA

举例

技术本质

Smart endpoints and dumb pipes

Smart pipes and dumb endpoints

应用场景

互联网行业

传统行业或企业内部

SOA，企业OA；微服务，电商平台

服务粒度

细

较粗

服务通信

标准化，轻量级

重量级

SOA，ESB；微服务，HTTP，RCP

服务交付

快速

较慢

微服务，服务小容易升级；SOA功能集中，较难升级

最初的应用都是单体架构，所谓单体架构就是将一系列功能全部集中在一个大的应用中，比如传统行业一般整个财务就做一个系统，将费用管理、账务管理、薪资结算等等都集中在一起，这种架构的局限性非常明显，不适合大规模项目的建设。

随着软件架构的发展，出现SOA架构，SOA将单体架构做了拆分，拆分成粗粒度的服务，同时将部分公共功能独立出来形成ESB，它的优点是

但是由于SOA架构需要一个统一的通信交互（ESB）， 导致了接口开发增加工作量。

更进一步发展，微服务架构出现，对服务进一步的拆分，拆分成更细粒度的服务；进一步提供了架构选择的多样性，微服务架构主要优点是

正是因为微服务将服务拆分的更小，它同样也带来了一些挑战，比如多服务运维难度增大、服务通信成本变高、数据一致性保持更难、性能监控要求提升等等。

所以业务在选择架构的时候，应从多方面考量选择更合适的架构。

顺便说一句，这里的架构演化是指整个架构的发展 历史 ，并不是说你的服务就一定要经过这个演化过程，只是更多的架构模式提供更多的选择。我们在做架构演进的时候，更多的是将单体应用演进到SOA架构或者演进到微服务架构。

面向中小企业的微服务产品提供自动应答菜单、微网站生成与管理、微信CRM系统服务、微信公众平台客服服务等综合性的运营管理标准化服务，是多功能的微信运营管理平台。

微信管家是将企业微信公众账号通过技术平台接入、运营管理等方式，帮助企业向微信用户提供更完备服务信息、用户互动体验、营销效果等企业应用解决方案。

为企业客户提供基于微信平台的客户服务、产品推介、互动营销、市场调查、产品订单等运营与系统功能

你好，很开心收到邀请来回答你的问题。

除了云计算、大数据和人工智能三大热门技术之外，Java被称为“编程开发的灵魂”，而微服务架构作为以Java为基础的高阶技能，同样不可忽视。

按照传统的软件开发模式，在开发项目时，通常我们会把项目创造成一个庞然大物，这个庞然大物包括一系列的小模块，比如“用户模块、订单模块、商品模块、支付模块”，一旦有模块掉了链子，整个项目都将Game Over!

为了解决这个问题，我们将一个大项目拆分成许多独立的小项目，每一个独立的小项目被称为服务。服务之间通过接口互相访问。即使某些服务挂掉，也不会影响其它服务的运行。这种项目架构称为微服务架构。

微服架构是整个互联网的框架核心，掌控了整个互联网的主心骨，一个好的架构就能搭建一个完美的互联网平台。因此，具有微服专业能力的架构师人才备受重视。

今年上半年，猎聘发布了《猎聘 2019 上半年中高端人才就业现状大数据报告》，在分领域热招数据统计中，架构师平均达到惊人的 万元，成为热门领域岗位薪资之最。

微服务架构系统灵活性，健壮性，扩展性好，特别适合需求变化迅速的场景。但系统复杂度高，部署，管理难度大。微服务除了开发期框架之外，还有需要一系列的运行期中间件支撑，如API网关，服务注册中心，统一配置中心等。 目前国内比较成熟的吧，东软有一支团队在做，他们网站是

1、作为企业API调用的统一出口和权限认证中心2、作为轻量级的企业级服务总线替换企业原有的ESB系统3、实现所有API接口的标准化、可视化、统一化管控4、作为微服务架构的核心API网关，集成到企业微服务架构中5、作为企业与供应链及合作伙伴的能力输出接口构建OpenAPI门户6、作为企业调用第三方API(京东、淘宝)等的统一API接入平台7、打通企业内部业务系统与外部业务系统之间的通道8、实现企业已有RestAPI、WebService、Dubbo、Kafka、MQTT等接口的注册和协议转换