Stay foolish,Stay hungry

1.前言

在上一篇文章《搭建DNS+LVS(keepAlived)+OpenResty服务器(Docker环境)》中,我搭建了dns+lvs+openresty+web集群；先来回顾一下架构图：

2.问题现象

可以看到，我把web服务器分成了两组，一组为web01,web02,挂在了openresty01下，另外一组:web03,web04,web05挂在了openresty02下；最后搭建完成，演示时，我分别使用了curl和浏览器，在curl演示时很正常，请求能轮流分到每个web容器，但在浏览器中演示时，刷新时显示轮流某一组web，而不是在所所有web应用轮流，我当时以为是浏览器缓存导致，所以新开了个页签；
我们来看一下：

现在上网已经成为每个人必备的技能，打开浏览器，输入网址，回车，简单的几步就能浏览到漂亮的网页，那从请求发出到返回漂亮的页面是怎么做到的呢，我将从公司中一般的分层架构角度考虑搭建一个简易集群来实现。目标是做到在浏览中输入网址，打开网页，而且每一层还具有高可用，只要一层中有一台主机是存活的，整个服务都将可用。

一、环境

• Centos 7
• Docker

  二、架构图

  

在开发过程中，我们有时需要将重要的错误日志通过邮件发送给相关的责任人，这样能即时发现错误，即时解决。如使用Log4J,一般会做如下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13

log4j.rootLogger = debug,mail

# 发送日志到指定邮件
log4j.appender.mail=org.apache.log4j.net.SMTPAppender
log4j.appender.mail.Threshold=INFO
log4j.appender.mail.BufferSize=10
log4j.appender.mail.From=from@qq.com
log4j.appender.mail.To=to@163.com
log4j.appender.mail.SMTPHost=smtp.qq.com
#发送邮件箱的用户
log4j.appender.mail.SMTPUsername=from@qq.com
#邮箱的授权码
log4j.appender.mail.SMTPPassword=

但是我在使用过程中发现标准的org.apache.log4j.net.SMTPAppender有如下几个问题。

题目

有一栋楼共N层，一个鸡蛋从第M层及以上的楼层落下来会摔破， 在第M层以下的楼层落下不会摔破。给你Q个鸡蛋，设计方案找出M，并且保证在最坏情况下， 最小化鸡蛋下落的次数。

这道题目经常在面试中问到，很多博客也给出了答案，但总感觉不全面，没有讲透彻，依据前人经验和自己的理解，从思路和实现两个方面进行思考，看一看采取哪一种算法合适。

为了简化问题，先假定有2个鸡蛋，100层楼。

假设最坏情况下，至多扔k次，那第一次需要在第k层扔下，会有两种情况：

1. 碎了。这时只剩下一个鸡蛋，只能从1层，一层层往下扔，最坏情况下从第k-1层扔下，如果在k-1层碎了，那N=k-1,总共扔了k次，如果没碎，那N=k，总共也扔了k次。
2. 没碎。这时手上还有2个鸡蛋，从k+1层开始往下扔，还可以扔k-1次，1到k层，最多扔k次，k-1次最多扔k-1层，所以第二次在k+k-1层往下扔，如果第二次扔没碎，第三次在k+k-1+k-2=3k-3层上扔，依此类推。
   所以得出，2个鸡蛋的时候，k次机会，最多可以从\(k+k-1+k-2+k-3+….+1 = \frac{k(k+1)} {2}\)层扔下，只要找到最小的k，使\(\frac{k(k+1)} {2} >= 100 \)，就找到了第一次扔的k层,容易得到k=14。
   这样就能保证在找到M时，扔的次数最多不超过14次。

0. prometheus/node_exporter/mysqld_exporter都是由go语言编写，需要先安装GoLang环境
1. 下载node_exporter(监控服务器的CPU、内存、存储使用情况)和mysqld_exporter放到Mysql服务器(被监控端)

• 需要为mysqld_exporter在Mysql数据库新建一个用户,并赋予相应权限

  1 2	CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'XXXXXXXX' WITH MAX_USER_CONNECTIONS 3; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

• 配置mysql_exporter启动时连接mysql的用户名和密码

  • 环境变量方式:

    1 2	export DATA_SOURCE_NAME='user:password@(hostname:3306)/' ./mysqld_exporter <flags>

  • 配置.my.cnf文件

    1 2 3 4 5 6

    [client] user=exporter password=exporter 然后启动mysqld_exporter mysqld_exporter -config.my-cnf=".my.cnf"

Dubbo的服务发布逻辑是比较复杂的，我还是以Dubbo自带的示例讲解，这样更方便和容易理解。

Provider配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?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:dubbo="http://dubbo.apache.org/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
 
    <!-- 提供方应用信息，用于计算依赖关系 -->
    <dubbo:application name="hello-world-app"  />
 
    <!-- 使用multicast广播注册中心暴露服务地址 -->
    <dubbo:registry address="multicast://224.5.6.7:1234" />
 
    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880" />
 
    <!-- 声明需要暴露的服务接口 -->
    <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />
 
    <!-- 和本地bean一样实现服务 -->
    <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />
</beans>

ApplicationContext

ClassPathXmlApplicationContext父类AbstractApplicationContext的方法refresh()在实例化bean之后的最后一步finishRefresh()中，此方法作用是发布相应的事件。

1
2
3
4
5
6
7
8

protected void finishRefresh() {
	//省略LifeCycleProcessor刷新代码

	// Publish the final event.
	publishEvent(new ContextRefreshedEvent(this));

	// 省略注册到 LiveBeansView MBean代码
}

可以看到发布了一个ContextRefreshedEvent事件。

1
2
3
4

protected void publishEvent(Object event, ResolvableType eventType) {
	//省略部分代码
  getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);
           //省略分部代码

前言

远程桌面控制的产品已经有很多很多，我做此项目的初衷并不是要开发出一个商用的产品，只是出于兴趣爱好，做一个开源的项目，之前也没有阅读过任何远程桌面控制的项目源码，只是根据自己已有的经验设计开发，肯定有许多不足，有兴趣的朋友欢迎留言讨论。

初现端倪

一般需要远程控制的场景发生在公司和家之间，由于公司和家里的电脑一般都在局域网内，所以不能直接相连，需要第三方中转，所以至少有三方,如下图。

负责中转的第三方是服务器，控制端和傀儡端(被控制端)相对于服务器来说都是客户端，都和服务器直接相连，也就是说控制端不和傀儡端相连。

款款深入

约定:

• 控制端M(Master)
• 服务器S(Server)
• 傀儡端P(Puppet)

为了叙述方便,以下如不做特别说明,M表示控制端,S表示服务端,P表示傀儡端。

SPI简介

SPI是Service Provider Interface的缩写，即服务提供接口(翻译出来好绕口,还是不翻译的好)，实质上是接口，作用是对外提供服务。
SPI是Java的一种插件机制，可以不用修改源代码实现新功能的扩展。
主要有如下几个步骤：

1. 实现SPI接口
2. 在项目的META-INF/services文件夹下，新建一个以SPI接口命名的文件， 文件里面配置上SPI接口的实现类
3. 使用java.util.ServiceLoader加载。
   由于本篇文章主要讲解Dubbo是如何使用SPI的，如果想要具体了解Java的SPI，可以参考下面两篇文章：

• JavaSPI机制学习笔记
• Introduction to the Service Provider Interfaces
  当然还可以看 java.util.ServiceLoader 源码，注释中也有详细的说明。

这篇文章是Dubbo源码分析的开端，与其说这篇文章是Dubbo源码分析，不如是spring源码分析，因为大部分都是在分析spring如何解析xml配置文件的，为了与后面的Dubbo源码分析保持一致，姑且这样命名了
使用Dubbo框架开发分布式服务时，一般使用spring进行管理，在spring的配置文件中进行配置，例如服务提供者Provider端配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?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:dubbo="http://dubbo.apache.org/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
 
    <!-- 提供方应用信息，用于计算依赖关系 -->
    <dubbo:application name="hello-world-app"  />
 
    <!-- 使用multicast广播注册中心暴露服务地址 -->
    <dubbo:registry address="multicast://224.5.6.7:1234" />
 
    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880" />
 
    <!-- 声明需要暴露的服务接口 -->
    <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />
 
    <!-- 和本地bean一样实现服务 -->
    <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />
</beans>

Replica Set在国内叫做副本集，简单来说就是一份数据在多个地方存储。

1.为什么要用副本集，什么时候使用副本集？

有人说一份数据在多个地方存储占用了大量的额外空间，是一种浪费。
这个说法不能说对也不能说不对，要从不同的角度考虑。如果公司的业务量很少，数据不多，一台服务器就可以搞定，那就不需要将一份数据存储在多个地方。随着公司的发展壮大，业务量越来越多，数据也越来越多，这时就需要考虑使用分布式集群的方式来解决了，将数据分散在不同的服务器中。此时仍可以不使用副本，通过将数据分散在不同的服务器中来分散各服务器的压力也可以跟上公司目前的业务量。如果公司规模进一步扩大，用户量越来越多，有可能很多客户要访问同一份资源，此时就有可能造成存放该资源的服务器压力过大。副本的必要性就显现出来了。

2.使用副本集有什么好处？

副本集提供了容错性，高可用性。当然容灾备份，读写分离等也使用到了副本。

3.MongoDB Replica Set集群介绍

为方便介绍，以下简称rs集群
(1).rs集群是由多个Mongod实例节点组成，其中只有一个节点是primary,其它节点是secondary，还有一个是可有可无的仲裁节点。当集群有偶数个节点时，通过会添加一个仲裁节点，如果集群有奇数个节点时，就不需要使用仲裁节点了。仲裁节点不存储数据，只用于投票选举出哪个节点是primary，而且仲裁节点不要求有专门的服务器，但不能运行在已经安装了primary或secondary节点的服务器上，可以运行在应用或监控服务器上(之前看到有人说仲裁节点除了投票外，还可以在primary节点失效后，在secondary节点中再选举出一个primary，这是不对的，仲裁节点的作用仅仅是有一票之权)。
(2).primary用于接收client的读和写请求，并记录操作日志，secondary用于从primary处异步同步primary的操作日志，并更新自己的数据集。通常情况下secondary不能响应client的读操作，以免读取脏数据。但rs集群有多个数据中心时，client可以请求读取secondary数据，当primay在北京的服务器上，其中一个Secondary在重庆，重庆的用户在读取数据时，考虑到地理位置和网速的关系，可选择只读primary，primary优先，只读secondary，secondary优先和读取最近(nearest)节点的数据。
(3).当primary不能访问时，剩下的secondary节点中会再选出一个primary节点。