Dubbo

最近几年，微服务大行其道。在业务模型不完善，超大规模流量的冲击的情况下，许多企业纷纷抛弃了传统的单体架构，拥抱微服务。这种模式具备独立开发、独立部署、可扩展性、可重用性的优点的同时，也带来这样一个问题：开发、运维的复杂性提高。有人感觉微服务越做越不方便管理。 然而，随着 Docker 容器技术和自动化运维等相关技术发展，微服务变得更容易维护。2020 年，微服务的发展只会越来越完善，成为将来大中型企业业务架构的主流趋势。 但微服务架构包含了 N 多优化、N 多细节，对于一些 coding 的朋友，由于接触不到一线实战架构设计，眼看别人都在向微服务架构转型，自己却只能日复一日地重复造轮子。 最近整理了一套微服务 视频 干货，讲解很透彻。今天分享给大家。这份资料 尤其适合 以下人群： 1.没有用过微服务技术，只会用传统的 SSM 框架 2.用过 Spring Cloud、Dubbo等技术，但是只限于使用，遇到问题基本无法解决 3.从来没有系统学习微服务架构，觉得架构设计是遥不可及的 4.对于微服务技术有所了解，但尚没有设计高可用高并发的实践经历 学完这份视频你将获得哪些收获？ 理解当下最火热的微服务架构原理及其开源框架； 触及一线大厂所配备的微服务核心技术内幕知识以及面试考核点； 对照自己掌握知识点进行查漏补缺，帮助扫除知识盲区、重构知识体系； 视频围绕“

前言： 自己也参与过app上的前后端分离项目，说是项目，其实就是app上一个新的功能。和其他功能不相干，所以不是在公司app项目基础上做的新增，而是一个单独的maven项目，具体到代码，自己参与的还只是CRUD，写service，以至于再去面试，别人问到这个前后端分离的一些具体问题，自己就答不上来。离开了上家公司，所以想把前后端分离模式下的一些细节问题弄懂。在网上买的这个教程。题目是《从无到有搭建中小型互联网公司后台服务架构与运维架构》，感觉这个正是自己想要了解的。学学吧，这里做一些记录，以便日后使用查阅。如有错误，请指教，谢谢！ 这是课程介绍的内容： 本课程主要是针对如何从无到有搭建中小型互联网公司后台服务架构和运维架构的课程，课程所涉及的内容均是当前应用最广泛的技术和工具。本课程所讲解的技术体系已经在多个中小型互联网公司中实战运行使用，目前运行已经非常稳定，数据量也是在不断持续增加。并且，这个技术体系也正在被其他很多互联网公司应用，希望通过此课程，让大家能快速熟练掌握各个技术，并且能实际应用到项目中。课程将会通过实际案例讲解，并且会提供完整的视频案例源码供学员学习使用，同时有需要的企业或学员可以直接拿本套教学案例代码来使用或者二次开发。 本课程设计的技术及工具如下： 后台服务架构：dubbo、spring-boot、spring mvc、spring-security

简介： 由阿里云主办的首届“云原生微服务大会”将于 2020 年 8 月 18-19 日在线上召开。本次大会聚焦微服务架构前沿发展和业界最佳实践，重点探讨云原生语境下微服务的挑战和技术趋势，帮助企业技术决策者、架构师、开发者们迎接云原生时代的到来。 最近，O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示，在访问了全球 1,502 名软件工程师、系统和技术架构师、工程师以及决策者后，有 77％ 的组织反馈采用了微服务，其中 92％ 的组织成功使用了微服务。 如果以这份报告为依据，微服务在企业的普及率已接近八成。看起来，企业对微服务的兴趣可能已经接近顶峰。 云原生的基础设施从设计上保证了它是微服务部署的最佳平台，但是也对现有的微服务框架带来了新的挑战 ，在云原生大行其道的今天： 我们对微服务还应该继续投入精力关注吗？ 云原生和微服务之间的关系是什么？ 随着 Serviece Mesh 等技术的不断成熟，微服务的体系和思想会产生怎样的演化？ Spring Cloud、Dubbo 还会继续作为微服务开发框架的继续流行下去吗？ 容器、Kubernetes、ServiceMesh、Serverless 这些云原生时代的主角，会如何助力下一代微服务架构为业务发展赋能？ 这些问题值得每一位技术从业人员去思考，并发现由此带来的企业数字化转型升级新挑战、新机遇。也许有同学会说：

解决Dubbo 2.7.3版本使用ConfigCenterConfig集成Apollo No Provider found的问题 参考文章： （1）解决Dubbo 2.7.3版本使用ConfigCenterConfig集成Apollo No Provider found的问题 （2）https://www.cnblogs.com/slankka/p/11431324.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4438370/blog/4955331

序言 dubbo就是个rpc框架，之前都是一直在用，现在稍微总结下以备以后使用。 我就直接贴代码了，代码肯定能运行，如果运行不了那么看我之前的zookeeper配置，或者把我贴的代码重新复制下，实在不行请留言，我看到会回复的。 整体项目结构 项目是父子maven结构，父maven中基础jar包都依赖好了，子maven只需继承父maven，额外依赖自己的jar包就可以，其中 domain 是放实体类的， interfaceapi 是放提供者提供给消费者的接口的。 provider 是提供者 consumer 是消费者，不过真实项目中可能一个模块即是消费者又是提供者。所以自己需要的话直接写就行，用法都一样的。 2.主pom文件 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion>

SpringCloud 什么是微服务？ 要想学习微服务，首先需要知道什么是微服务？为什么会有微服务？相信看完架构的发展史读者就会明白 架构发展史 单体应用架构 如图所示：将所有的模块，所有内容(页面、Dao、Service、Controller)全部写入一个项目中，放在一个Tomcat容器中启动 适用于小型项目 优点：开发速度快，可以利用代码生成工具快速的开发一个项目 缺点：不易扩展，代码耦合度高，且不容错(当某部分出错后整个服务就会停止运行) 垂直架构 既然原来单体架构中代码耦合度高，不利于维护和运行，人们自然就想到将不同的内容分开。最简单合理的方式就是将系统按照功能划分成不同的模块，然后将各模块独立放入不同的Web容器中，这就形成了垂直架构 优点：代码耦合度降低，且不同模块之间可以独立运行。一旦某个模块压力过大，可以针对性的搭集群 缺点：模块之间有可能不是那么完全独立，导致实体类或者其他层代码不能复用，需要多出粘贴，不方便日后维护。如果直接通过HTTP调用又不是很合理。 分布式架构/分布式SOA架构 分布式架构顾名思义就是分散部署在不同的机器上的服务，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的架构。从开发的角度看就是Controller层(服务消费者)和Service层(服务提供者)分成不同的项目

作者|孙棋(空蒙) 出品|阿里巴巴新零售淘系技术部 导读：当前移动互联网业务研发运维模式，云与多端互相割裂，有些全栈的探索缺乏成功案例，行业对云端一体化研发这块仍是空白，我们要思考： 如何能实现 1 个研发支撑云 + android + iOS 三端的业务快速落地。 是否有新的研发运维模式，让程序员回归程序，“一次编码、到处运行”是我们的答案。我们在闲鱼项目验证，原本 60 天的项目时间减少了 20 天，提效 33% 。希望本文的分析也能够给大家带来收获。 业务研发模式的演进 效率是业务研发运维模式演进核心驱动力 PC 互联网时代，单体应用包含前后端是最初的研发模式（淘宝经历开发人员写 velocity 模板，以及更早的 jsp、asp 页面）其实质是中心化搭火车的研发模型。 随着业务发展复杂性快速增加，赶火车的交付模式，极大的限制了业务发展，因此诞生了服务化的拆分，淘宝在 09 年的五彩石项目即基于这样的背景，微服务是一种软件架构，这背后更是一种研发模式的变革，从中心化研发模式到分布式的研发模式升级。 在业务分布式研发模式升级的同时，前后端分离研发模式也在同步的演进，从 ajax 到专业前端独立完成业务闭环，职业分工细化提效。但对前端同学而言，服务端的运维始终是其痛苦的技术门槛，以及在阿里以 Java 语言为基础的中间件生态内，一直没有很好解决。 进入移动互联网时代

前言 这次去阿里面试的是我老东家的好朋友，我们之前都是一个项目组的，一起吃饭，一起洗脚，一起。。。 他们公司最近也裁员了，不过他是裁员前去的阿里，不知道谁捞到他简历了，莫名就走了流程，他莫名的就面了7轮过了。 他想着行情这么不好，要不就去了，去了之后，他们公司就裁员了。。。 总之今年大环境真的很差，大家都时刻做好准备，我朋友简历上是写了精通dubbo的源码，所以你们会发现，面试中dubbo的问题很多，他面经写得算是比较简单，但是真实问的过程肯定会扣肯定细节。 正文 面试总共花费20天左右，包含4轮电话面试、1轮笔试、1轮主管视频面试、1轮hr视频面试 第一轮 电话面试（基础知识为主，约2小时）： 1，先自我介绍，包含日常工作 2，基础知识 1）多线程（ThreadLocal（问了父子线程怎么共享数据 interitableThreadLocals）、lock和sync区别（问HashMap1.7、1.8区别时带出）、AQS原理（执行过程源码，入队出队的细节，源码细节）、CountDownLatch和CyclicBarrier的区别是什么源码级别、volatile从指令重排序，内存屏障，聊到总线风暴）所占比重较大 2）数据库（mysql索引（聚集索引、非聚集索引、索引结构（顺带会问各种树的特性）、执行计划、count1*区别、举例优化sql、MVCC和事务隔离级别的关系、间隙锁、行锁

前言 很久没有写关于 Spring 的文章了，最近在系统梳理 Dubbo 代码的过程中发现了 XML schema 这个被遗漏的知识点。由于工作中使用 SpringBoot 比较多的原因，几乎很少接触 XML，此文可以算做是亡羊补牢，另一方面，也为后续的 Dubbo 源码解析做个铺垫。 XML schema 扩展机制是啥？这并不是一块很大的知识点，翻阅一下 Spring 的文档，我甚至没找到一个贯穿上下文的词来描述这个功能， XMLSchemaAuthoring 是文档中对应的标题，简单来说： Spring 为基于 XML 构建的应用提供了一种扩展机制，用于定义和配置 Bean。 它允许使用者编写自定义的 XML bean 解析器，并将解析器本身以及最终定义的 Bean 集成到 Spring IOC 容器中。 Dubbo 依赖了 Spring，并提供了一套自定义的 XML 标签， <dubbo:application> , <dubbo:registry> , <dubbo:protocol> , <dubbo:service> 。作为使用者，大多数人只需要关心这些参数如何配置，但不知道有没有人好奇过，它们是如何加载进入 Spring 的 IOC 容器中被其他组件使用的呢？这便牵扯出了今天的主题：Spring 对 XML schema 的扩展支持。 自定义 XML 扩展 为了搞懂

背景 在 Dubbo 中，可以使用 XML 配置相关信息，也可以用来引入服务或者导出服务。配置完成，启动工程，Spring 会读取配置文件，生成注入 相关 Bean。那 Dubbo 如何实现自定义 XML 被 Spring 加载读取？ Spring XML Schema 扩展机制。从 Spring 2.0 开始，Spring 开始提供了一种基于 XML Schema 格式扩展机制，用于定义和配置 bean。 Spring XML Schema 扩展机制 实现 Spring XML Schema 扩展，其实非常简单，只需要完成下面四步。 创建 XML Schema 文件，由于该文件后缀名为 xsd，下面称为 XSD 文件。 编写实现一个或多个 BeanDefinitionParser 。 编写 NamespaceHandler 实现类。 注册 NamespaceHandler 以及 XSD 文件。 我们按照以上步骤,最终完整 Spring 解析如下配置。 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:demo=