今天做两个服务器数据的迁移，数据文件很大，打完包好几个G，直接下载到本地再上传到另一个服务器不现实，下载速度才10-20kb/s，估计要迁移一辈子

于是研究了下scp命令，scp命令主要是用于服务器之间传输数据，其命令格式如下：

scp 文件所在主机用户@文件所在主机IP:文件带路径名 本级存储位置

当然也可以在文件所在的主机做发送，则命令格式如下：

scp -r 待传输的文件 目标主机用户@目标主机名:目标主机存储文件位置

而执行scp命令后，就会有一个下载进度条和速度，几十G的文件，速度很慢，于是尝试了下直接用nohup，但是就无法输入目标主机的密码了，当然可以用密钥免密码方式，但是因为嫌麻烦。。采用了更粗暴的方

先执行scp拷贝命令，运行中，看着龟速的下载速度，按 ctrl + z 暂停任务

这时使用

jobs

可以查看到，刚才的命令被停止了

这时候，使用

bg %1

将命令转入后台模式，这时使用

之前一直在用RN开发应用，最近Flutter很火，就研究了下，而大家在开发与服务端做接口交互时，为了保证安全性，基本上都会使用加密方式来隐藏通讯内容，非对称加密方式，相比其他固定算法加密方式要安全很多，

非对称加密使用了私钥、公钥来分别对数据进行解密、加密操作，公钥做加密后的数据，只有私钥才能解密，因此会非常的安全。

Flutter使用的是Dart语言，Dart语言和Java非常的像，基本上会使用Java的程序员可以直接上手，部分查下就Ok了。

在Dart中，非对称加密可以使用 encrypt 包，可以直接在 pubspec.yaml 中增加 encrypt: ^2.0.0 即可完成包的引用，当然，不要忘记执行 packages get

做非对称加密，就必须要有公钥和私钥，特别注意一点，当前的 encrypt 为2.0.0版本，当前仅支持 PKCS#1文件格式的密钥

首先我们要生成私钥bash\nopenssl genrsa -out private_key.pem 4096这样就生成了一个私钥，而且就是PKCS#1格式的，如果有PKCS#8格式的，也可以用这个命令来转换为PKCS#1bash\nopenssl pkcs8 -in pkcs8_private_key.pem -nocrypt -out pkcs1_private_key.pem

第一个坑，在flutter中，密钥文件直接存放在目录中是无法使用File读取到的，只能放在asset中才可以，所以需要在 pubspec.yaml中增加相关密钥文件才行，例如将密钥文件存放在与 pubspec.yaml 同级的目录 keys 下，则需要在 pubspec.yaml 中增加如下代码

assets:
  - keys/private_key.pem
  - keys/public_key.pem

之后我们可以在代码中使用

String publicKeyString = await rootBundle.loadString('keys/public_key.pem');

来获取到公钥的文本，再通过

维持了一年半的忙碌，突然而来的失业

终于，一段为期十天的旅行，让我放松了下，感觉心里好受多了。

下一步，有一些计划，要开始忙起来了

*玉龙雪山

我去旅行了，暂时停更…放松下调整心态。。。

go-micro是一个go语言的微服务框架，可以大幅度的提升开发效率，并完成一套微服务的架构，其架构借用官方的图

go-micro的架构图

其项目地址github: https://github.com/micro/go-micro

首先go-micro框架是一套微服务分布式的框架，其拥有以下特性：

• 服务注册/发现
• 负载均衡
• 消息解码，并默认支持json以及protobuf
• 基于rpc的请求响应
• 异步的消息通讯
• 最后也是我觉得最牛的一点，接口可插拔，你可以不管用运行环境到底是使用的etcd或者consul来做服务发现，是使用http或rabbitmq做通讯，使用kafka做订阅还是用rabbitmq或者redis，是的，所有的一些都是可以插拔的，只要在运行时加入对应的启动参数，就可以使用对应的插件

有人可能第一次接触微服务这个词，微服务的概念，可以理解为，讲一个单一应用，拆分成一套小型服务的方法，每个服务都做单独的部署，单独的开发，内部甚至可以使用不同的语言来实现。微服务的理念在传统的单机部署中并未见到明显的优势，但当越来越多的应用被部署到云中的时候，微服务的优势就立刻体现出来了，包括：

单应用共用数据库，而微服务每个服务使用不同或相同数据库

• 独立部署，每个服务独立去部署，独立运行于不同的进程，使得每个服务可以根据负载做部署数量调整
• 服务降级，当系统负载增高，需要对某些关键业务做优先增配时，可以对不关键、低级别的业务做服务降级，临时关闭某些服务来保证关键业务的稳定
• 功能单一，技术选型更广，由于微服务的功能相对单一，可以针对不同的微服务采用更适合的编程语言、数据库等，例如做朋友关系、二度好友功能就考虑使用neo4j的图形数据库，底层稳定性要求高的微服务则可以通过Java来开发，并发比较高的微服务则可以考虑使用Go来开发等等
• 后期维护隔离，对功能的后期开发升级不会影响整体的应用稳定性
• 单独测试，单独开发，可以使每个微服务由不同的团队去开发、去单独测试，增加了整体开发的速度
• 复用性，多个不同的应用可以直接复用某个微服务

单应用不同模块运行在单一进程中，而微服务则每个服务运行于不同的进程

而go-micro正是这样一个针对微服务开发的框架，其将所有热插拔的插件发布于go-plugins，开发者可以根据需求引用，同时在运行时追加响应的运行参数即可启用插件。

好了，这章简单的介绍了go-micro这个框架以及微服务的概念，下一章讲开始go-micro的源码解析

好吧，因为公司缘故，现在我是真的闲下来了，近期将有时间更新了，可以边更新边找工作了。。计划更新以下几个方面：

• go-micro源码解析，因为之前一段时间在学习go并用go-micro来重构了一些项目代码，所以准备来一个系列文章解析go-micro源码
• 架构方面的文章，因为前半年一直在和架构调整，自动部署，集群化这些devops做斗争，准备写一系列这个方面的文章
• 其他一些随想吧，毕竟这一年半忙的要死，最后结果挺坑的。。

暂时只想到这些，先这样吧。。希望这个flag我能坚持下去。。