Dubbo

题图 From unsplash 翻开年初用脑图整理的计划，拧巴着硬是往完成上面靠，还是没全部达成，生活总是这样，如果都能达成真应了那句老话：万事如意，一帆风顺，事事顺心。 前两天整理了今年的书单[ 2018年大龄程序员书单 ]，有些囫囵吞枣，有些细嚼慢咽，不敢说从书中学到了多少东西，只希望某一天能用书中所述解决些实际问题。剩下的问题就是把书单中拉出来未读的读完。 微信公号文章90+，中间有些朋友的投稿，算来也写两年半的时间，找到点写作的感觉。当然还摆脱不了功利心，盼着有多少阅读量，多少订阅量。2019年要提高写作频率，提高读书笔记的数量。 从珠海去了趟澳门，也算是见识了另一个制度下的中国。出去走走的计划是完成了，但个人锻炼的计划近乎荒废，没有持续性。越发感觉有个好身体是多么的重要，行业里那么多猝死的新闻也是让人胆寒心惊。 新年里行、动起来，此flag为证。 技术学习上没有原定计划走，更多的关注点放在了大前端与区块链上面。前端技术近几年百花齐放，如果不停的学习前端框架的话，几乎跟不上更新的速度。作为后知后觉者接触到了比特币、区块链，顺手也买了些，亏的很惨是肯定的。嗅觉敏感度还差很多，不能有效捕捉到机会。搞技术的，对市场总欠缺些经验，跟工种是对内的有一定关系，更多的还是与个人有关系。[ 技术设计的狭隘性 ] 某媒体称今年只要你不碰加密币、不碰A股、不碰P2P、不碰风险系数高的基金等等

最近频繁地在跟实习生候选人打交道，每次新接触一个候选人，都要花上一定的时间去介绍我们团队，候选人问的最多的一个问题就是「中间件部门一般是干嘛的？」，恰好我之前也接触过一些想从事中间件开发的小伙伴，问过我「现在转行做中间件开发还来得及吗？」诸如此类的问题，索性就写一篇文章，聊聊我个人这些年做中间件开发的感受吧。 什么是中间件开发？ 我大四实习时，在一个 20 多人的软件开发团队第一次接触了中间件，当时项目的架构师引入了微博开源的 RPC 框架 Motan，借助于这个框架，我们迅速构建起了一个基于微服务架构的内部电商系统。接着在项目中，由于业务需求，我们又引入了 ActiveMQ...在这个阶段，我已经在使用中间件了，但似乎没有接触到中间件开发，更多的是使用层面上的接触。 我毕业后的第一份工作，公司有几百号研发，当时的 leader 看我对中间件比较感兴趣，有意把我分配在了基础架构团队，我第一次真正意义上成为了一名”中间件研发“，平时主要的工作，是基于开源的 Kong 和 Dubbo，进行一些内部的改造，以提供给业务团队更好地使用。这个阶段，做的事还是比较杂的，业务团队对某些中间件有定制化的需求，都需要去了解这个中间件，熟悉源码。这段时间，也是我成长最快的一个时期，我是在这个期间学会了 Docker、Neo4j、Kong 等以前从来没接触过的技术，并且更加深入地了解 Dubbo 这类

1、Dubbo架构图 角色说明： 来源： oschina 链接： https://my.oschina.net/u/4285706/blog/4270683

单体架构（all in one） 所有模块都在一起，技术也不分层。 在单机上部署所有的应用程序和软件。 所有的代码都写在JSP里面，所有代码都写在一起，这种方式称为all in one。 特点： 1.不具备代码的可维护性。 2.容错性差。（容错性是指软件检测应用程序所运行的软件和硬件中发生的错误并从错误中恢复的能力，可以从系统的可靠性，可用性，可测性等几个方面衡量） 因为所有代码都写在JSP页面里，当因为用户或某些原因发生异常时：用户可以直接看到异常错误信息；异常会导致服务器宕机。 单体地狱： 只需一个应用，将所有功能部署在一起，以减少部署节点和成本。 解决方案 1.分层开发：解决单体架构容错性差的问题，同时提高了代码的维护性。 2.MVC架构（Web应用程序的设计模式） 3.服务器的部署分离。 特点： 1.MVC分层开发：解决容错性问题。 2.数据库和项目部署分离。 <font color=red>问题</font>： 1.高并发：随着用户访问量的持续增加，单台服务器无法满足用户访问需求。 解决方案： 1.集群 集群操作可能遇到的问题 高可用 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。 如何保证高可用：避免单点。 高并发 高并发

作者 | 于雨 来源| 阿里巴巴云原生公众号 本文源自 2020 年 12 月 20 日作者在云原生社区 meetup 第二期北京站演讲 《Apache Dubbo-go 在云原生时代的实践与探索》的部分内容，如果对演讲完整内容感兴趣请访问： https://www.bilibili.com/video/av245840877 自从以 2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术登上舞台之后，相关技术从业人员从认知和体感上接受，云原生时代真的到来了。 当然也有很多资深技术人员认为，云原生时代要从 2010s 时以 OpenStack 为代表的虚机编排时代开始。当然，也有人说其实云原生技术诞生很早，可以从巨型机时代在巨型机上虚拟出若干小型机开始追溯。 在云原生时代，不变镜像作为核心技术的 docker 定义了不可变的单服务部署形态，统一了容器编排形态的 k8s 则定义了不变的 service 接口，二者结合定义了服务可依赖的不可变的基础设施。有了这种完备的不变的基础设置，就可以定义不可变的中间件新形态 -- 云原生中间件。 云原生时代的中间件，包含了不可变的缓存、通信、消息、事件(event) 等基础通信设施，应用只需通过本地代理即可调用所需的服务，无需关心服务能力来源。 微服务框架 从最早的单体应用时代到分布式技术时代

在Linux，你是不是曾经天真的以为，使用rm删除一个文件，占用的空间就释放了？事情可能不是常常如人意。 产生一个指定大小的随机内容文件 我们先看一下当前各个挂载目录的空间大小： $ df -h /dev/sda11 454M 280M 147M 66% /boot 我这里挑选了其中一个结果展示（你可以选择任一挂载目录），接下来准备在 /boot 下生成一个文件。 首先我们产生一个50M大小的文件： $ dd if=/dev/urandom of=/boot/test.txt bs=50M count=1 至此，我们产生了一个50M大小的文件，再看boot下： $ df -h /dev/sda11 454M 312M 115M 74% /boot 这里你不用关心到底多了多少，你只需要关注，/boot下的文件增多了。 测试程序： #include<stdio.h> #include<unistd.h> int main(void) { FILE *fp = NULL; fp = fopen("/boot/test.txt", "rw+"); if(NULL == fp) { perror("open file failed"); return -1; } while(1) { //do nothing sleep(1); } fclose(fp); return 0; }

前言 上云目前已经是绝大数企业首选的IT基础设施建设方案，但是云上仍然存在一些不确定因素（机房硬件故障、网络故障、断网/断电、人为操作失误），导致各大云厂商每年在不同的数据中心都会发生一些故障，所以建设具备容灾能力的业务应用是必需的。公共云上容灾解决方案涵盖同城双活、跨Region容灾和异地多活等容灾场景，对公共云上大多数中长尾客户来说，更需要的是一种对应用侵入性小甚至透明，但又能保证高可用的容灾方案，同城双活无疑是首选的容灾方案，大多数业务应用只要做到同城双活，就可以避免掉大多数数据中心不可用故障。 本实践就是帮助大家高效、低成本地实现自己的业务应用具备同城双活容灾能力。通过这篇文章可以基于EDAS高效的实现同城双活容灾，在实现这些容灾场景的同时需要其他的阿里产品配合，也会一并介绍对应的解决方案，可以参考下面架构图： 鉴于目前需要做容灾的主流架构都已经拆分为微服务架构，而且微服务架构本身也是一种具备更强容灾高可用能力的架构。微服务架构一般由网关（统一接入层）、RPC框架（Dubbo，Spring Cloud）、消息(MQ)、分布式数据库、缓存等核心软件构成，通过EDAS可以高效地实现入口流量切流、RPC路由容灾、多可用区部署等能力，参考下图： 方案主要产品介绍 EDAS 企业级分布式应用服务 EDAS（Enterprise Distributed Application

作者 | 行松 阿里巴巴云原生团队 来源 | Serverless 公众号，整理自 《Serverless 技术公开课》 背景 通过前面几节课程的学习，相信大家对于 SAE 平台已经有了一定的了解，SAE 基于 IaaS 层资源构建的一款 Serverles 应用托管产品，免除了客户很多复杂的运维工作，开箱即用、按用量付费；并且提供了丰富的 Open API 可以很容易地与其他平台做集成。 本文将为大家介绍 SAE 在微服务方面的一些能力，SAE 产品把 Serverless 技术和微服务做了很好的结合，天然支持 Java 微服务应用的托管和服务治理，对 SpringCloud/Dubbo 微服务应用能够在只修改配置和依赖，不修改代码的情况下迁移到 SAE 上，并提供服务治理能力，比如基于租户的微服务隔离环境、服务列表、无损下线、离群摘除、应用监控以及调用链分析等。 本次课程分为三部分来介绍，分别介绍微服务应用迁移到 SAE 的优势，如何迁移 SpringCloud/Dubbo 应用到 SAE 上，以及针对 SpringCloud 应用迁移的实践演示。 迁移到 SAE 的优势 在介绍迁移之前，先介绍下 SpringCloud/Dubbo 应用迁移到 SAE 的优势： SAE 内置注册中心 ：所有用户共享注册中心组件，SAE 帮助用户运维，这就节省了用户的部署、运维成本

作者 | 行松 阿里巴巴云原生团队 本文整理自 《Serverless 技术公开课》 ，“Serverless”公众号后台回复“入门”，即可获取系列文章 PPT。 背景 通过前面几节课程的学习，相信大家对于 SAE 平台已经有了一定的了解，SAE 基于 IaaS 层资源构建的一款 Serverles 应用托管产品，免除了客户很多复杂的运维工作，开箱即用、按用量付费；并且提供了丰富的 Open API 可以很容易地与其他平台做集成。 本文将为大家介绍 SAE 在微服务方面的一些能力，SAE 产品把 Serverless 技术和微服务做了很好的结合，天然支持 Java 微服务应用的托管和服务治理，对 SpringCloud/Dubbo 微服务应用能够在只修改配置和依赖，不修改代码的情况下迁移到 SAE 上，并提供服务治理能力，比如基于租户的微服务隔离环境、服务列表、无损下线、离群摘除、应用监控以及调用链分析等。 本次课程分为三部分来介绍，分别介绍微服务应用迁移到 SAE 的优势，如何迁移 SpringCloud/Dubbo 应用到 SAE 上，以及针对 SpringCloud 应用迁移的实践演示。 迁移到 SAE 的优势 在介绍迁移之前，先介绍下 SpringCloud/Dubbo 应用迁移到 SAE 的优势： SAE 内置注册中心： 所有用户共享注册中心组件，SAE 帮助用户运维

Sentinel: 分布式系统的流量防卫兵 Sentinel 是什么？ 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Sentinel 具有以下特征: 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。 Sentinel 的主要特性： Sentinel 的开源生态： Sentinel 分为两个部分: 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo /