您访问的是非正式的站点,不是最新内容哦,请点击这里前往Dnocm ヾ(=゚・゚=)ノ喵♪

若白驹过隙,忽然而已

在今天,加入了Google Ads,不过更多的是想体验一下广告的收益以及对页面浏览的影响。我使用的是自动广告,但自己访问,完全没有任何广告的影子,不知道是不是配错了。如果亲们访问时对你们造成了影响(或者发现了广告的影子),可以截个图,通过右下角的Chatra联系我。

对页面访问有影响的话会下掉广告,毕竟没国际信用卡,就算赚了也取不出来。
去掉去掉,毕竟每天只有1-2pv,一个月也就半百人访问这个小破站,而且谷歌广告需要点击才收费,点击一次3毛。。。。(2019.1.15写)

另外页面会使用Google分析。。。这个可能对国内用户访问造成影响,请尽量在VPN下访问该站点,vultroutline是不错的方案,或者可以看一下我的VPN教程

又双叒叕加回来啦😂—2019.7.28

缘由

有时候不想打开电脑修改文章,所以需要一个管理页面代替电脑操作(简单的能修改),一般而言,存在两种方案实现它

  • 调用GitHub(或者其他Repo)的Api,获取与修改文件
  • 通过Git命令获取修改以及推送文件

但无论那种都存在安全问题,如果在本地操作,那么完全没必要管理站点,不是本地的话且使用静态托管的话(如GitHub Page),如何确保是自己修改呢?这就需要一个安全服务,但本身只是偶尔修改使用,撘一个安全服务似乎不划算,所以这件事就一直搁置着

前段时间,我将静态服务迁移到了Netlify,发现它居然提供了CMS用于管理静态资源,我体验了Gatsby的例子,能上传媒体文件,能添加与修改文章,相对的安全性(Netlify会获取你的Git仓库很多权限,但我不认为它会做恶意破坏的行为)…满足了我的要求。

一些重要的,有争议的点

  • 边界 - 《领域驱动设计》
  • 服务版本管理
  • 公用数据
  • 安全性
  • 报表

再过去的一段时间,感觉一直在原地踏步,虽然偶尔也有写几篇文章,但几乎都是在翻旧账

但总不能一直这样下去吧

所以准备在接下来有所改变

新的域名(dnocm.com),我会再近期将其他站点迁移到这上面

新的博客Lofter,准备写一些其他兴趣相关的(Code外,动漫、游戏?),虽然目前还是零记录

新的CI/CD,使用Netlify做静态托管,能自动https,GitLab 3年前就开始讨论与准备集成Let’s Encrypt,但。。。

新的邮箱(有新域名自然换啊),i@dnocm.com欢迎联系

新的封页(https://www.dnocm.com/cover),可能调整到根路径下,打算用Web Components重写,打算中。。。

大半年前就写过一篇文章[《测试驱动开发(TDD)的实践》](https://www.dnocm.com/articles/almond/test-driven development/),关于测试的。时至今日,我仍然坚信测试是软件开发一重要环节,它在绝大多数情况下,保障了系统的质量与稳定性。

但当时所搭的框架存在一些不足,当然主要是由于Asciidoctor。这是一个足够完善的标记语言,但也足够复杂。然而大多数情况下我们并不需要这些语法,Markdown正好足够。

事实上,当时我最先尝试的也是Markdown,使用Spring Restdoc中推荐的Slate方案,来解决Markdown无法包含问题。缺点是它运行使用的Ruby,与我所学的完全不同(Java、Js)。但最近看到了另一个文档工具Docsify,它也添加了包含功能,它足够简单,以至于看几遍例子就完全学会,虽然也有缺点,SEO方面,但内部接口文档,你会在乎这个么?下面是一个例子整合Restdoc与Docsify

背景

在微服务中,单个服务的升级改善是不可避免的,虽然改动最终引起Rest接口变动并不多,但仍然会出现。在《微服务设计》中,提供了两种处理方案:

  1. 不同的接口共存
  2. 同时运行多个版本服务

这本书的作者Sam Newman,他认为这两种方案都是可行的,但更倾向于不同接口共存。也提出了三点主要原因

  • 当出现问题时,不同的接口共存可以更快的修改新老版本的代码并一同部署,而另一种就比较麻烦了
  • 方案二维护困难,同时存在多个版本服务,对运维来说具有较大的挑战性
  • 持久化层可能是一样的,方案二却有不同版本的实现,会导致潜在的复杂性

但我更倾向于方案二,该方案的实际使用者主要是Netflix(Spring Cloud便是基于他开源的微服务框架研发的),在现阶段(2018年)相对于作者的年代(2015年),技术上已经有了较大的变化。微服务的设计已经在很多公司大规模的推行及使用,变得更加成熟。作者所提出的前两点问题已经有了比较好的方案减少影响

如果您和我一样,喜欢更新至最新的主题,那么您也应该遇到和我一样的烦恼。每次更新新的主题时,总是要重新配置,而且随着自定义的内容增多,更新就成了负担。

因此,引入了Fork与Submodules来实现以下目标

  1. 自动合并自定义内容与配置
  2. 校验更新操作是否正常工作

如果您不了解如何使用hexo搭建博客,您可以参考这篇博客:https://www.dnocm.com/articles/almond/gitlab-pages-for-hexo/

Feign是轻量级、声明式的Http请求客户端,它吸收了来自的Retrofit JAXRS-2.0和WebSocket的灵感,为了使写Http请求变得更容易而诞生

Feign一开始作为Eureka的子项目,用于简化Http请求。但由于其不断完善,目前作为一个轻量级、声明式的Http请求客户端项目,独立维护。在Spring Cloud中,其引入了Feign,并提供了一系列默认的配置与Spring MVC注解的支持。因此,Feign一直被作为首先的Http请求客户端。

在微服务架构中,服务发现是最重要的一环。Spring Cloud提供多个服务注册中心作为选择,如Eureka、Consul、Zookeeper等,当然最常用的是Eureka

简介

Eureka由Eureka Server与Eureka Client两部分组成
Eureka Server是高可用的(可同时作为客户端向其他注册中心注册)服务发现的注册中心,为每个客户端(Eureka Client)提供注册服务,并提供已注册服务信息
Eureka Client向服务注册中心注册,并提供断路、负载均衡等功能