Dubbo

前言： 现在IT界跳槽已成常态，跳槽，可能有以下原因: 技术达到瓶颈，无法在此公司有好的提升，前几年我感觉基本不会出现，至少我现在没出现。 实力与薪资不匹配。 和同事 领导不和，如果你在几家公司都这样，要自我检讨一下是不是自己的问题。 仅个人观点，其他诸如地域 情感 兴趣等个人原因不做讨论。 这也导致很多企业在用人时会比较在意员工的稳定性一般外包公司都会比较忙，相对来说，成长应该是比较快的，而你的工作性质偏业务，那么你要想清楚一个问题，以后你的发展轨迹是怎样的？是在技术方向越走越远呢，还是在管理方向发展呢？ 一、 微服务架构专题（思维导图） 二、微服务是干什么的 我对于微服务最大的体会就是：对于云平台来说，如果元数据驱动的平台组件是骨骼，那么微服务和触发器就是串联骨骼的经络和血脉没有经络和血脉，一堆组件仅仅是静态的，不能变化，没有反馈，更何谈交互。而一个PaaS平台可以孵化无数个SaaS应用，每个应用都需要使用一套小服务来开发，而为了防止应用搭建复杂化和避免后期难以维护，所以每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP AP（Rest的方式，这就是为什么我能看到那些标签的存在）。好处体现在以下方面： 这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署（体现在平台就是微服务站点部署和独立微服务站点部署） 这些服务可以使用不同的编程语言实现（只要实现结果

个人博客地址 studyidea.cn ,点击查看更多原创文章 踩坑 公司最近新建一个机房，需要将现有系统同步部署到新机房，部署完成之后，两地机房同时对提供服务。系统架构如下图： 这个系统当前对外采用 Restful 接口，内部远程采用 Dubbo ，服务注册中心使用 zookeeper 。服务当前设定只会调用本机房内服务。 原先服务都在 A 机房，B 机房为新建机房。B 机房部署完成之后，需要测试 B 机房系统可用性。生产测试的发现 B 机房竟然调用 A 机房服务。 A/B 机房网络互相打通，可以互相访问 通过排查 B 机房服务日志，发现 Service B 一个服务节点注册 IP 解析错误，将 B 机房机器 IP 解析成 A 机房机器 IP 。 于是当测试流量进入 B 机房时， openapi 服务通过注册中心获取到错误的 Service B 服务地址，从而调用了 A 机房的服务。调用方式简化成如下图。 知识点：Dubbo 服务提供者启动时将会将服务地址（ IP +端口）注册到注册中心，消费者启动时将会通过注册中心获取服务提供者地址（ IP +端口），后续服务调用将会直接通过服务地址直接调用。 问题分析 Debug Dubbo 源码，定位到 IP 解析代码，位于 ServiceConfig#findConfigedHosts ，源码如下： Dubbo 版本为 2.6.7

 系统拆分 将一个系统拆分为多个子系统，用 Dubbo 来完成；每个系统连一个数据库。 缓存 大部分的高并发场景，都是读多写少，你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存就可以节省磁盘读写浪费的资源。毕竟 Redis 轻轻松松单机几万的并发。所以可以考虑在项目里承载主要请求的读场景，怎么用缓存来抗高并发。 MQ 如果出现了高并发写的场景就要考虑用 MQ了。大量的写请求灌入 MQ 里，后边系统消费后慢慢写，控制在 mysql 承载范围之内。所以在项目里，那些承载复杂写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。MQ 单机抗几万并发也是可以的。 分库分表 分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 sql 执行的性能。 读写分离 读写分离，大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。 ElasticSearch Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为资源不够时就可以扩容加机器来扛更高的并发。那么比较简单的查询、统计类的操作，可以考虑用 es 来承载

作者 | 唐志龙（鲲龙） 阿里巴巴高级开发工程师 导读 ：本文总结了熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 前言 开发人员经常会面临下面一些场景： 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习？ 被拉过去参与一个陌生系统的迭代开发或者系统维护（bugfix），如何快速上手？ 同事离职或转岗，需要把系统交接给你，怎么去接？ 内心 os：这是一口锅吗？ 这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 业务学习 业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。 常见问题： 系统所在行业的情况是怎样？ 系统的目标用户是谁？比如是给公司高层做决策用

1. 微服务简介 1.1 什么是微服务架构 微服务架构是系统架构上的一种设计风格 将大系统拆分成N个小型服务 这些小型服务都在各自的线程中运行 小服务间通过HTTP协议进行通信 有自己的数据存储、业务开发、自动化测试和独立部署机制 可以由不同语言编写 小结：微服务架构的思想，不只是停留在开发阶段，它贯穿了设计，研发，测试，发布，运维等各个软件生命周期。 2. 架构体系 架构样例： 2.1 微服务发布--持续集成 3. 微服务架构九大特性 服务组件化 -- 组件是可独立更换、升级的单元。就像PC中的内存，CPU一样。 按业务组织团队 -- 要求人员全栈技能 做“产品”的态度 -- 对整个产品生命周期负责，而不是做“项目”交付态度 智能端点与哑管道 -- 微服务间的通讯方式： --- HTTP的RESTful API --- MessageMQ消息队列 去中心化治理 --不是每一个问题都是钉子，不是每一个解决方案都是锤子。 去中心化数据管理 --独立维护各服务数据存储，尽量使服务间“无事物”调用，通过补偿机制维护数据一致性问题 基础设施自动化 -- 自动化测试 -- 自动化部署 容错设计 -- 每个服务实现监控和日志组件，比如服务状态，断路器状态，吞吐量，网络数据等关键数据仪表盘 演进式设计 --初期单体，逐步拆分，抽取公共组件 4. 微服务选型 Dubbo

问题1：为什么要把系统拆分成分布式的？为啥要用dubbo？ 1.为什么要将系统进行拆分？ 要是不拆分系统，一个大系统几十万行代码，很多人共同维护一份代码，简直是悲剧； 拆分了以后，一个大系统拆分成很多小服务，平均每个系统也就几万行代码，每个服务部署到单独的机器 2.如何进行服务拆分？ ​ 大部分系统，是要进行多轮拆分的，第一次拆分就可能将原来的多个模块拆分开来。 ​ 但是后来可能每个系统都变得很复杂了，每个模块拆分出来的服务又要继续拆分。 3.拆分后可以不用dubbo吗？ ​ 当然可以，大不了各个系统之间，直接基于springmvc，就通过纯httpj接口互相通信。但是这里肯定是由问题的，因为HTTP接口通信维护起来成本很高，要考虑超时重试,负载均衡等各种问题。 所以dubbo说白了，就是一个rpc框架，就是本地就是进行接口调用，但是dubbo会代理这个调用请求，跟远程机器网络通信，处理负载均衡，服务上下线自动感知，超时重试等问题，就不用我们自己做，交给dubbo。 ​ 问题2：说一下dubbo的工作原理，注册中心挂了可以继续通信吗？说一下一次rpc请求的流程？ 1.dubbo工作原理 2.dubbo分层 第一层：service层，需要服务提供方和消费方来实现 第二层：config层，配置层，主要是对dubbo的各种配置 第三层：proxy层，服务代理层

　　网页静态化解决方案在实际开发中运用比较多，例如新闻网站，门户网站中的新闻频道或者是文章类的频道。 网页静态化技术和缓存技术的共同点都是为了减轻数据库的访问压力，但是具体的应用场景不同，缓存比较适合小规模的数据，而网页静态化比较适合大规模且相对变化不太频繁 的数据。另外网页静态化还有利于SEO。另外我们如果将网页以纯静态化的形式展现，就可以使用Nginx这样的高性能的web服务器来部署。Nginx可以承载5万的并发，而Tomcat只有几百。 一.FreeMarker简介 　　 FreeMarker 是一款 用 Java 语言编写的模板引擎 ： 即一种基于模板和要改变的数据， 并用来生成输出文本(HTML网页， XML，JSP 或 Java 等)的通用工具。 它不是面向最终用户的，而是一个Java类库，是一款程序员可以嵌入他们所开发产品的组件。 中文在线文档: http://freemarker.foofun.cn/ 二.FreeMarker使用步骤 1.第一步：工程中引入FreeMarker依赖 <!-- FreeMarker的坐标 --> <dependency> <groupId>org.freemarker</groupId> <artifactId>freemarker</artifactId> <version>2.3.23</version> </dependency

ali bab a有好几个 分布式 框架 ，主要有：进行远程调用(类似于RMI的这种远程调用)的(dubbo、hsf)，jms消息 服务 (napoli、notify)，KV 数据库 (tair)等。这个框架/ 工具 / 产品 在实现的时候，都考虑到了容灾，扩展，负载均衡，于是出现一个配置中心(ConfigServer)的东西来 解决 这些 问题 。 基本 原理 如图： 在 我们 的 系统 中，经常会有 一些 跨系统的调用，如在A系统中要调用B系统的一个服务，我们可能会使用RMI直接来进行，B系统 发布 一个RMI 接口 服务，然后A系统就来通过RMI调用这个接口，为了解决容灾，扩展，负载均衡的问题，我们可能会想很多办法，alibaba的这个办法感觉不错。 本文只说dubbo，原理如下： ConfigServer 配置中心，和每个Server/Client之间会作一个实时的心跳 检测 （因为它们都是 建立 的Socket长连接），比如几秒钟检测 一次 。收集每个Server 提供 的服务的信息，每个Client的信息，整理出一个服务列表，如： service Name serverAddressList clientAddressList UserService 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 172.16.0.1

pom: <dependency> <groupId>com.github.sgroschupf</groupId> <artifactId>zkclient</artifactId> <version>0.1</version> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.8</version> <type>pom</type> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.5.3</version> <exclusions> <exclusion> <!--当在Maven中有包的冲突的时候，为解决包的冲突，我们可以在依赖中排除依赖--> <artifactId>spring</artifactId> <groupId>org.springframework</groupId> </exclusion> </exclusions> </dependency> 服务提供者： <?xml version="1.0" encoding="UTF-8"?

1、相关依赖引入 阿里的dubbo包含了spring相关内容，引入依赖时，需要排除，使用我们自己项目中的spring依赖 <!-- start..............dubbo.................--> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.5.3</version> <exclusions> <exclusion> <artifactId>spring</artifactId> <groupId>org.springframework</groupId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.6</version> </dependency> <dependency> <groupId>com.github.sgroschupf</groupId> <artifactId>zkclient</artifactId> <version>0.1</version> </dependency>