Motan

点击上方“ JavaEdge ”，关注公众号 设为“ 星标 ”，好文章不错过！ RPC框架主要组成 通信框架 通信协议 序列化和反序列化格式 1 分类 RPC框架主要分为： 1.1 绑定语言平台 1.1.1 Dubbo 国内最早开源的RPC框架，由阿里巴巴公司开发并于2011年末对外开源，仅支持Java 架构 Consumer 服务消费者 Provider 服务提供者 Registry 注册中心 Monitor是监控系统 交互流程 Consumer 通过 Registry 获取到 Provider 节点 再通过Dubbo的客户端SDK与Provider建立连接，并发起调用 Provider 通过Dubbo的服务端SDK接收到 Consumer 请求 处理后再把结果返回给Consumer 服务消费者、提供者都需引入Dubbo的SDK才来完成RPC调用，因为Dubbo是用Java实现，所以要求服务消费者、提供者也都必须用Java。 主要实现 默认采用Netty作为通信框架 除了支持私有的Dubbo协议外，还支持RMI、Hession、HTTP、Thrift 支持多种序列化格式，比如Dubbo、Hession、JSON、Kryo、FST 1.1.2 Motan 微博内部使用的RPC框架，于2016年对外开源，仅支持Java。 架构 与Dubbo类似，都要在Client端（服务消费者

Envoy为什么能战胜Ngnix——线程模型分析篇 导读：随着Service Mesh在最近一年的流行，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。作者是Envoy的开发者之一，本文详细说明了Envoy的线程模型，对于理解Envoy如何工作非常有帮助。内容较为深入，建议细细品读。 关于Envoy的基础技术文档目前相当少。为了改善这一点，我正在计划做一系列关于Envoy各个子系统的文章。 这是第一篇文章，请让我知道你的想法以及你希望涵盖的其他主题。最常见的问题之一是对Envoy使用的线程模型进行描述。 本文将介绍Envoy如何将连接映射到线程，以及Envoy内部使用的线程本地存储（TLS）系统，正是因为该系统的存在才可以保证Envoy以高度并行的方式运行并且保证高性能。 线程概述 图1：线程概述 Envoy使用三种不同类型的线程，如图1所示。 Main：此线程可以启动和关闭服务器。负责所有xDS API处理（包括DNS ， 运行状况检查和常规集群管理 ）， 运行时 ，统计刷新，管理和一般进程管理（信号， 热启动等）。 在这个线程上发生的一切都是异步的和“非阻塞的”。通常，主线程负责所有不需要消耗大量CPU就可以完成的关键功能。 这可以保证大多数管理代码都是以单线程运行的。 Worker：默认情况下，Envoy为系统中的每个硬件线程生成一个工作线程。（可以通过-

你知道的越多，你不知道的越多 GitHub地址 https://github.com/AobingJava/JavaFamily 已经开源，有面试点，欢迎【Star】和【完善】 前言 Redis在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（请允许我使用一下夸张的修辞手法）。 于是在一个寂寞难耐的夜晚，我痛定思痛，决定开始写《吊打面试官》系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 絮叨 上一期因为是在双十一一直在熬夜的大环境下完成的，所以我自己觉得质量明显没之前的好，我这不一睡好就加班加点准备补偿大家，来点干货。（熬夜太容易感冒了，这次点个赞别白嫖了！） 顺带提一嘴，我把我准备写啥画了一个思维导图，以后总不能每篇都放个贼大的图吧，就开源到了我的GitHub，大家有兴趣可以去完善和Star。 这篇我就先放出来大家看看，感觉还是差点意思，等大家完善了。 回望过去 上一期吊打系列我们提到了Redis相关的一些知识，还没看的小伙伴可以回顾一下 《吊打面试官》系列-Redis基础 《吊打面试官》系列

前言 随着技术日新月异的发展，最近几年微服务和分布式技术成为主流。每一个好的解决方案不一定是直接设计出来的，但每一个优秀的架构都必须承受得住业务的考验和需求驱动的积累。最初我们开发系统都是在单个的应用上进行开发、测试、部署和运维等。每次新的需求迭代都将可能涉及到整个系统的修改，尤其是庞大而臃肿的业务系统需要进行大量的数据增删改查操作，开发起来变得非常麻烦。为了应对更高的并发和业务需求，解决单个应用的缺点，把庞大复杂的单体应用按照业务拆分成多个子业务模块，可进行垂直拆分或水平拆分，从而达到更高效的开发、更好的管理和维护的目的，这就是所谓的分布式系统。 一、单体架构是什么？ 1.1 定义 一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。 1.2 单体应用举例 单体应用集成了前端页面和后端接口服务及业务逻辑和数据操作于一体的单个完整系统，Struts1、Struts2及SSH、SSM架构的系统等，单个应用囊括了所有业务模块。 1.3 单体架构示意图 1.4 单体应用优缺点 1.4.1 优点 易于集中式开发、测试、管理、部署。 无需考虑跨语言。 能避免功能重复开发（相对分布式）。 1.4.2 缺点 团队合作困难 代码的维护、重构、部署都比较难。 稳定性、可用性（停机维护）、扩展性不高。

第一章 微服务与 Spring Cloud 1.1 架构的衍进 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 互联网产品常常面临庞大的用户量，日均数十亿 PV 的高并发， PB 级别的数据存储等问题的挑战，同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。 互联网架构从简到繁的演进至今，大体上可分为这么几个阶段：单一应用架构 -> 垂直应用架构 -> 微服务架构。 1.1.1 单一应用架构 当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，用来减少部署节点和成本。这时，用于简化增删改查工作量的数据访问框架(ORM)是关键。我们更加关注的是简化开发工作。如图1-1： 特点： 所有的功能集中在一个工程中。 应用与数据库分开部署。 通过部署应用集群和数据库集群来提高系统的性能。 优点： 项目架构简单，前期开发成本低，周期短，小型项目的首选。 缺点： 全部功能集中在一个工程中，代码耦合，对于大型项目不易扩展及维护。 提高系统性能只能通过扩展集群，成本高。 单点容错率低。 1.1.2 垂直应用架构 · 当访问量逐渐增大，功能逐渐复杂起来，单一应用架构就显得有些捉襟见肘，由于所有的功能都写在同一个工程中

在面试前，以及在工作中（我常说，要以随时准备面试的状态准备着😃），作为一个Java开发，应该需要准备一些技能和知识，以提升自己并拿下面试。不知道的一定要及时深入地补上，并记下笔记，最好是写成博客。 对于我们很多开发的人来说，最近工作中使用的技术可能会相对熟悉；而没用的或是用过了后来不怎么用的，自然的就渐渐地忘了（毕竟人脑这个内存还是有限的，成本也很高，不用的就放到外存吧），因此深入地学习并记录以便后续我们更容易复习。 其实我们也都知道，现在面试要求都很高，有句话怎么说来着？“面试造航母，工作拧螺丝”，这从侧面说出了一个问题，如果你不会造航母，连拧螺丝的机会都得不了（当然有创业能力的人除外）；当然，也从另一个侧面说明了（某一层次的）开发人员的数量很多，催生出了一些畸形行业现象。我们说的封装理念（对使用者透明）哪里去了？框架说好的要让开发更专注核心业务的开发哪里去了？为什么要去了解很多东西的原理、源码实现等等，一个Java开发还要了解运维、容器等等？ 我想这是有道理的，开源在这个行业做得很好，既然是Free Software，那么你可自由地修改，有了问题不会有专门的商业公司为你服务，那么只能自己去解决，所以还得知道源码。都说程序员是目前 仅存的纯手工工种 ，但也是自动化程度很高的工作，都是计算机😃。运维和开发已然交织，因此什么构建、容器、架构等等都得知道。既然选择了就坚持下去吧。

原文: 微服务架构 微服务架构到底应该如何选择？ 什么是微服务？ 微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。 微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。 主要有一下几个特点 服务拆分粒度更细 微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。 服务独立部署 每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码。 服务独立维护 每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。 服务治理能力要求高 因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。 微服务架构下，服务调用主要依赖下面几个基本组件： 服务描述 注册中心 服务框架 服务监控 服务追踪 服务治理 开源RPC框架介绍 Dubbo

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。 Motan 是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。 rpcx 是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。 gRPC 是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。 thrift 是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。 以下是它们的功能比较： 对于RPC的考察， 性能是很重要的一点，因为RPC框架经常用在服务的大并发调用的环境中，性能的好坏决定服务的质量以及公司在硬件部署上的花费。 本文通过一个统一的服务，测试这四种框架实现的完整的服务器端和客户端的性能。 这个服务传递的消息体有一个protobuf文件定义： syntax =

一、引子 “ 微服务”近年来很火的一个词，如今的热度不亚于当年的SSH组合，各种开发框架、中间件、容器、概念层出不穷。 比如：dubbo、motan、zookeeper、springboot、springcloud、kafka、docker等技术框架； 比如：服务注册、发现、降级、治理、网格，柔性事物、TCC概念、CAP理论、脑裂、DevOps等概念； 以上所列仅仅是其中的一部分，部分技术或概念可能很早就有可能当时并不流行，只因现今互联网技术的潮流与微服务的缘故现在又被大家关注使用了起来。 要想不被技术潮流所淘汰，提高自身价值拿高薪，作为程序猿的我们唯有不断学、学、学。。。。。 二、如何学习 学习的关键个人觉得一定要理论与实践相结合，看过的理论、概念一定要落地实践，这样理解才能深刻、细节才能掌握，可能部分公司并不具有这样的学习环境，想学没机会，自学又怕坚持不下来，迷失方向，那怎么办呢？ 往下看： 三、JCloud的诞生 看了诸多理论，技术大佬的分享，心中一直想实现一套较为完整的基于微服务架构的基础开发框架，至少目前主流的一些解决方案、理论实践一遍。最后决定选择SpringColud体系作为基础，研发一套微服务开发框架，故而框架命名为 JCloud（ 也想不到其他的名字，先这么叫吧 ） 并且完全开源 , 今天只是开篇， 后续会不断更新系列博客。 JCloud简要介绍：一些浅度的封装

调用示例 同步调用 Pom中添加依赖 <dependency> <groupId>com.weibo</groupId> <artifactId>motan-core</artifactId> <version>RELEASE</version> </dependency> <dependency> <groupId>com.weibo</groupId> <artifactId>motan-transport-netty</artifactId> <version>RELEASE</version> </dependency> <!-- only needed for spring-based features --> <dependency> <groupId>com.weibo</groupId> <artifactId>motan-springsupport</artifactId> <version>RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>4.2.4.RELEASE</version> </dependency> 为调用方和服务方创建公共接口 src