其实微服务框架是什么的问题并不复杂，但是又很多的朋友都不太了解微服务包括哪些方面，因此呢，今天小编就来为大家分享微服务框架是什么的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！
微服务架构实践中，服务是如何通信的
微服务之间的通信，一般都是借助于微服务框架完成，一般有REST风格的api通信，和微服务框架结合的RPC.
REST风格的api通信所谓的REST风格的api通常来讲就是HTTP结合来使用，但是要遵循REST规范的HTTP有如下特征.
统一接口
无状态
缓存
客户端-服务器
分层系统
按需代码（可选）
RPC通信RPC(RemoteProcedureCall)远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用，RPC允许你像调用本地函数一样去调用另一个程序的函数，这中间会涉及网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过「发送请求-接受回应」进行信息交互的系统。
RPC通信通常和微服务框架结合，框架会定于消息的序列化格式，比如谷歌的gRPC框架就是利用protobuff序列化，来序列化消息之后通信。
常见的微服务框架有：Dubbo
是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。ApacheDubbo|?d?b??|是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。2011年末对外开源，仅支持Java语言。
官网：http://dubbo.apache.org/zh-cn/
Dubbo架构图|图片来源dubbo.apache.org
Tars
腾讯内部使用的微服务架构TAF（TotalApplicationFramework）多年的实践成果总结而成的开源项目。仅支持C++语言，目前在腾讯内部应用也非常广泛。2017年对外开源，仅支持C++语言。
源码：https://github.com/TarsCloud/Tars/
TARS架构图|来源github.com/TarsCloud
「本命鹅厂TARS框架介绍PPT已下载，不想自己麻烦去找的同学，在我公众号「后端技术学堂」回复「tars」获取。」
Motan
是新浪微博开源的一个Java框架。Motan在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。于2016年对外开源，仅支持Java语言。
官方指南：https://github.com/weibocom/motan/wiki/zh_userguide
Motan框架|图片来源github.com/weibocom/motan
gRPC
是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(ProtocolBuffers)序列化协议开发。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。2015年对外开源的跨语言RPC框架，支持多种语言。
中文教程：https://doc.oschina.net/grpc?t=58008
gRPC架构图|图片来源www.grpc.io
thrift
最初是由Facebook开发的内部系统跨语言的高性能RPC框架，2007年贡献给了Apache基金，成为Apache开源项目之一，跟gRPC一样，Thrift也有一套自己的接口定义语言IDL，可以通过代码生成器，生成各种编程语言的Client端和Server端的SDK代码，支持多种语言。
thrift架构|图片来源wikimedia
创作不易，看到这里动动手指，点赞「三连」是对我持续创作的最大支持，我们下篇文章再见！
文章每周持续更新，可以微信搜索公众号「后端技术学堂」提前看，或在公众号回复「资料」有我给你准备的各种编程学习资料，我们下期见！
微应用和微服务区别
微服务适合体量较大、迭代需求较多的业务。与微服务应用相对应的是单体应用，应用服务+数据库服务是最原始的单体架构模型。在应用功能简单、用户数量有限的情况下，从用户端并不能感受到微服务和单体应用的差别。
但对于服务端开发来说，可能微服务应用开发运维工作量更复杂，毕竟微服务架构本质上是分布式架构，需要一层基础设施，搞定服务注册与发现、分布式配置管理、负载均衡、服务网关、断路器之类的问题
微服务架构和分布式架构的区别
微服务架构是指将一个大型的应用程序拆分成多个小型独立的服务，每个服务都有自己的功能和特点，并可以独立部署和运行，彼此之间通过API进行通信和交互。微服务架构的优点是系统解耦、服务可维护，可伸缩性好等。而分布式架构则是指将一个应用程序分布式地部署在多个物理节点上，每个节点拥有自己的计算资源和存储资源，各节点之间通过网络传输数据和协同工作。分布式架构的优点是可以充分利用多节点的资源，提高系统的容错性和可靠性，但开发和维护难度也相应增加。简单说，微服务架构更注重服务的拆分和解耦，而分布式架构更注重整个系统的资源利用和协同工作。
微服务架构是什么现在国内能落地吗
微服务与SOA架构
微服务
维基上对其定义为：一种软件开发技术-面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTfulAPI）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
微服务概念的由来是怎么样的呢，参考维基百科英文版，简单梳理后的微服务出现的历史：
2005年：Dr.PeterRodgers在WebServicesEdge大会上提出了“Micro-Web-Services”的概念。2011年：一个软件架构工作组使用了“microservice”一词来描述一种架构模式。2012年：同样是这个架构工作组，正式确定用“microservice”来代表这种架构。2012年：ThoughtWorks的JamesLewis针对微服务概念在QConSanFrancisco2012发表了演讲。2014年：JamesLewis和MartinFlower合写了关于微服务的一篇学术性的文章，详细阐述了微服务。顺便说一句，这几个人都是大名鼎鼎的，名字可能陌生，但是摆出他们的作品，相信多少是有些了解的。MartinFlower是《重构》、《UML精粹》的作者；RobertMartin，人称Bob大叔，敏捷专家，《代码整洁之道》、《架构整洁之道》的作者。既然微服务是SOA架构的一种变体，那么，谈微服务，SOA就是一个跨不过去的一个话题。
SOA
SOA的全称是“ServiceOrientedArchitecture”，中文翻译是“面向服务架构”，1996年，由Gartner公司最早提出SOA概念。它的诞生是有其历史背景的。
公司内部所有部门都有自己独立的IT系统随着每个部门的业务发展，独立的IT系统的复杂度越来越高同时，基于这样的背景，Gartner公司提出了SOA的概念，并且还给了一个预言，它预言在2008年，SOA会成为一种最流行的、且占有绝对优势的软件工程实践办法。
基于你对软件行业发展的关注和理解，Gartner公司关于SOA的预言是否靠谱呢？很显然，Gartner的预言并不是很准确，虽然在一段时间内SOA的概念、设计思路有占据过一段热点排行，但最终它也将成为架构历史长河中的一个匆匆过客。这也正是验证了那句话：“没有最好的架构，只有最合适的架构”
SOA架构图：SOA架构示意图
很多时候，我们认为SOA已经消失在江湖，实际上并非如此，许多传统行业，比如物流、仓储行业的系统都是采用SOA架构来构建的。
对于SOA，从图中可以看到，它的每一项业务功能都是一个服务，都需要对外提供服务的能力，来完成企业所需的各项业务功能，也就意味着它具有对外提供开放的能力，这些能力无需定制化就可以实现。为什么无需定制化呢，核心就在于ESB。
ESB（EnterpriseServiceBus）即，企业级服务总线，ESB是SOA架构中的核心，起着将企业中不同异构系统的连接在一起的作用。它本身提供了消息路由、协议转换等等能力。通过ESB，SOA架构实现了服务与服务之间的松耦合，减少了各个服务间的依赖和相互影响。每项服务只需要关注自身对外提供的能力即可，无需关注其他服务是怎么实现的。
看到ESB的功能，是不是觉得它的功能有点似曾相识？是的，它就是微服务所需要的基础服务。
微服务架构简而言之，微服务架构风格，是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务能力构建的，并且可以通过全自动部署机制独立部署。这些服务的集中管理最少，可以用不同的编程语言编写并使用不同的数据存储技术。
图：微服务架构示意图
上面一段话是MartinFowler关于微服务架构论文中的核心片段，从上述片段中，我们提炼出微服务架构的核心有三点：
其一是“小服务”，将应用拆分为一组小服务；
其二是“在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信”，微服务是由独立进程且进程之间通过轻量级机制进行通信；
其三是“可以通过全自动部署机制独立部署”，也就是说每个微服务可以快速独立部署。
其实这已经非常精确、精准的描述出了微服务的基本特征。完全可以作为在微服务架构实践中落地的三个参考依据与检验标准。
微服务与SOA对比对比维度
微服务
SOA
举例
技术本质
Smartendpointsanddumbpipes
Smartpipesanddumbendpoints
应用场景
互联网行业
传统行业或企业内部
SOA，企业OA；微服务，电商平台
服务粒度
细
较粗
服务通信
标准化，轻量级
重量级
SOA，ESB；微服务，HTTP，RCP
服务交付
快速
较慢
微服务，服务小容易升级；SOA功能集中，较难升级
应用架构的演化图：应用架构的变迁
最初的应用都是单体架构，所谓单体架构就是将一系列功能全部集中在一个大的应用中，比如传统行业一般整个财务就做一个系统，将费用管理、账务管理、薪资结算等等都集中在一起，这种架构的局限性非常明显，不适合大规模项目的建设。
当项目逐渐变大后，代码量逐渐增多，会出现编译、打包费时，严重影响效率。当业务逐渐增多后，不同的业务创建不同的项目，不同的项目的功能模块可能会出现重复建设的情况，造成浪费。随着软件架构的发展，出现SOA架构，SOA将单体架构做了拆分，拆分成粗粒度的服务，同时将部分公共功能独立出来形成ESB，它的优点是
把模块拆分，使用接口通信，降低模块之间的耦合度把项目拆分成若干个子项目，不同的团队负责不同的子项目增加功能时只需要在增加一个子项目，调用其它系统的接口就可以可以灵活的进行分布式部署但是由于SOA架构需要一个统一的通信交互（ESB），导致了接口开发增加工作量。
更进一步发展，微服务架构出现，对服务进一步的拆分，拆分成更细粒度的服务；进一步提供了架构选择的多样性，微服务架构主要优点是
开发简单，每个服务都尽可能的小。独立提供更小的业务能力。技术栈灵活，不需要在乎使用什么语言、数据存储方式等服务独立无依赖，每个服务都能独立部署、独立运行独立按需扩展，更少的依赖，更高的扩展性高可用性，独立模块，即使一个进程宕机也不影响整体服务能力。正是因为微服务将服务拆分的更小，它同样也带来了一些挑战，比如多服务运维难度增大、服务通信成本变高、数据一致性保持更难、性能监控要求提升等等。
所以业务在选择架构的时候，应从多方面考量选择更合适的架构。
顺便说一句，这里的架构演化是指整个架构的发展历史，并不是说你的服务就一定要经过这个演化过程，只是更多的架构模式提供更多的选择。我们在做架构演进的时候，更多的是将单体应用演进到SOA架构或者演进到微服务架构。
什么是微服务
所谓的微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。
微服务设计原则：1、各司其职。2、服务高可用和可扩展性。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
