Mobility的 RSS 预览

Vaadin框架教程：Java工程师的前端开发秘籍

2024-03-06 19:36:22

后端工程师开发前端的痛点，通常来说莫过于太过繁琐，经常要为了一些很小的事查半天。Vaadin很好的解决了这个痛点，为后端工程师提供易上手、方便使用的前端代码编写解决方案，今天我们就来了解一下。

大家好，今天跟大家介绍一个对后端工程师特别有价值的工具——Vaadin。

说起来，上手前端基本的html, css开发，确实并不难，但是如果只会这些基本的东西，开发起来会很繁琐。如果想要使用前端生态中的各种轮子，虽说便利度提升了，但学习成本也会同步上升。所以，如果不是职业的全栈工程师，只是作为一个后端，想临时写点前端代码，比如自己想做点小项目，通常来说都会有个很痛苦的过程。

Vaadin很好的解决了这个痛点。通过vaadin包装好的常用前端组件，我们几乎可以零学习成本的编写出功能完备、不太难看的页面。对于后端背景的程序员来说，无疑会大幅度降低自己做些小项目的成本。

Vaadin提供的功能，就是可以直接用java代码来写页面。Vaadin提供了多种输入框、表单等等封装好的前端样式，而且与springboot做了深度的融合，使用起来非常方便。

Vaadin的实际原理并不复杂，主要是基于服务端渲染，即在后端生成最终的html代码，交给浏览器。服务端渲染，这个并不罕见，与客户端渲染的优势和劣势，我们在这里不多讲。当然，对于vaadin来说，使用服务端渲染，似乎也没什么好说的，毕竟是写的后端代码，直接在后端做渲染，是个再正常不过的实现路径。Vaadin的引擎对前后端之间的交互做了封装，所以对使用者来说，前后端之间的交互是无感的，在页面层，我们也可以正常的调用后端service.

下面是我写的一段代码示例，可以更直观的感受Vaadin的作用：

@Route(value = "path", layout = MainView.class)
@PageTitle("路径规划")
public class PathView extends VerticalLayout {

    @Autowired
    private PathService pathService;

    public PathView() {
        TextField start = new TextField();
        TextField end = new TextField();
        HorizontalLayout path = new HorizontalLayout();
        path.add(start, end);
        Button pathCalculate = new Button("calculate path");

        VerticalLayout result = new VerticalLayout();
        TextField transferNum = new TextField();
        TextField distance = new TextField();
        Text stations = new Text("");
        result.add(
                new H3("换乘数: "),
                transferNum,
                new H3("总距离 :"),
                distance,
                new H3("途径站点详情:"),
                stations
        );

        pathCalculate.addClickListener(click -> {
            PathInfoVO pathResult = pathService.getPath(start.getValue(), end.getValue());
            System.out.println(pathResult);
            stations.setText(StringUtils.join(pathResult.getDetail(), ","));
            transferNum.setValue(String.valueOf(pathResult.getTransferNum()));
            distance.setValue(String.valueOf(pathResult.getDistance()));
        });

        add(
                new Text("hello world"),
                path,
                pathCalculate,
                result
        );
    }
}

这段代码中，我们完全使用java代码对页面中的各个组件进行了编排，包括button的click函数，也是使用java开发者习惯的方式定义，并且能够直接调用其他后端service, 可以说是几乎零学习成本了。

详细代码和运行效果，可以到项目地址中查看。

如果你对Vaadin感兴趣，或者有任何问题或想法，欢迎在评论区交流。一起探索如何更好地利用Vaadin，提升我们的开发效率吧！

原文地址： https://lichuanyang.top/posts/43947/

hexo多语言方案总结及最佳实践

2024-01-22 18:12:31

对于hexo的多语言方案，官方并没有提供很完备的支持，但是网络上有很多人尝试过不同的解决方案。今天，我们对这些方案简单做个总结，看看我们需要的多语言方案是什么样子的。

其实，hexo的多语言方案，说白了就是两个思路，一个是在文章维度切换语言，借助hexo原生的能力和hexo-generator-i18n等插件，用一套框架维护两个语言的内容；另一个则是独立维护不同语言的样式、内容，在站点维度切换语言，只是在域名层面合并到同一个域名。

具体要选择什么方案，取决于大家想要一个什么样的多语言网站。一开始我想象中的多语言网站的是第一种，即统一的首页，在首页和每篇文章上都支持切换语言，对每篇文章，可以通过切换语言，直达对应的其他语言译文上。

这个思路，借助于hexo-generator-i18n插件，可以实现，但要做比较多的定制开发。所以，我又重新思量了一下思路，我要的多语言网站应该是什么样。重新考虑之后，逐渐觉得第二种思路才是更合理的。我们要做一个多语言网站的目的是什么？对我来说，其实就是要获取一些英文流量。作为一个未备案网站，已经很久无法获取百度的搜索流量了，google在中国占的份额又太低，所以单凭中文内容，很难从搜索中获取较高流量。所以我希望通过提供一些英文内容，获取英文流量。这个目标下，完全不需要对所有的文章都维护多语言版本。何况，不同文章的语言受众也的确有很大区别，所以，语言的切换可以直接在站点层面进行。

具体操作方式上，一种是直接维护多个站点，两个站点内容、样式完全独立，只是部署在同一个域名下。比如中文站点根路径是lichuanyang.top，英文站点根路径是lichuanyang.top/en . 两个站点上各做一个跳转链接，向对方跳转。

我采用的是另一种方式，相比上述方式，成本小一些，不需要实际维护两个站点。原理大致如下：

在本地，同样维护两个站点。但是英文站点不会去做实际的部署，只是用作生成静态网页的工具。英文版的内容生成之后，直接复制到中文网站的对应目录下，只对中文网站做部署即可。

具体操作步骤如下：

将博客目录整体复制一份，作为英文博客目录. 例如，我的博客根目录叫blog.source, 复制出一个blog.source.en. 这步完成后，如果博客源码也是以git维护的，可以直接在原目录的外层直接新建一个git项目，在外层做管理就行了。示例如下：
1
2

blog(git根目录)/blog.source
/blog.source.en
将en目录下的文章全部删除；站点描述等文本调整为英文内容；英文语言设置为en；英文站点根 (_config.yml中的root配置)设置成/en
在两个站点下增加跳转链接。我是借助菜单功能，直接在菜单里加一个其他语言项。 next主题中配置如下：
1
2
3

中文站： English: /en || fa fa-language
英文站：中文: https://lichuanyang.top || fa fa-language
之后配置基本就完成了，可以在en目录下写英文文章，流程与之前写中文文章时完全一致
最后就是生成和发布环节了，这一步要注意，每次生成时，我们需要先生成中文站点，再生成英文站点并将英文内容复制到中文目录下，避免生成中文内容时将英文内容覆盖掉。具体操作示例如下：
1

hexo clean && hexo g &&cd ../blog.source.en && hexo clean && hexo g && cd ../blog.source &&cp -r ../blog.source.en/public/. public/en/ && hexo s
命令最后一段，使用hexo s就是本地启动，使用hexo d就是发布出去，和正常使用时一样。

这样，我们就有了一个好用的多语言站点了。之后，写中文内容就在中文目录下进行，写英文内容就在英文目录下进行, 最后执行一下上边的命令就可以了。

原文地址: http://lichuanyang.top/posts/40400/

知乎增强工具-评论时间精确到秒

2023-12-22 17:24:18

一个优化知乎显示的油猴工具

之前在小众软件上看到一个知乎评论区时间展示混乱的吐槽，有大佬立刻就给了一个油猴脚本。

用了一段时间很舒服，然后前几天知乎做了个更新，导致展示开始混乱。研究了一下，做了更新，想着就发布到GreasyFork上吧，后边知乎再有调整，可以直接从线上更新。

脚本地址：安装地址

大家感兴趣的话，欢迎留言，后边考虑做个油猴脚本的开发教程。

原文地址: http://lichuanyang.top/posts/44912/

怎么理解数据库的四个隔离级别

2023-12-08 17:12:44

数据库的事务隔离级别实际上是个很好理解的东西。

但是在一些劣质博客和公众号的努力下，这块知识已经成功的成为了一片烂八股。

接下来，只需要顺着我的思路，回答几个简答的问题，就可以将事务隔离级别理解透彻。

问：怎么实现不同事务直接的隔离？

对这个问题，当你处于讨论数据库事务隔离级别语境下时，是不是觉得很难回答？然后先把数据库三个字从脑子里剃掉，不同事务，也就是不同线程，操作数据怎么做隔离？答案是不是很简单？就是加锁。

问：锁有哪些类型

答：有很多种分类方式。在这里，我们把锁分成读锁和写锁。

问：加不同级别锁时，代码的表现会有什么区别？

到这里，原问题的答案是不是就呼之欲出了。

事实上，数据库事务为什么会有这些个不同的隔离级别，就是因为不同场景下使用了不同的锁。比前边说的稍微复杂的点，就是数据库中存在范围锁，在其他领域不太常用，就是把某一段数据整体锁住。

如果我们把所有操作能加的锁都加上，实际上就是串行化的操作了。这种方式隔离性当然很好，但性能就没法说了，所以一般也不会有人使用。

可重复读则是对涉及到的数据加读锁和写锁，并持有到事务结束，但不会加范围锁。这样就会出现幻读的问题，即一个事务内执行两次范围查询，如果这两次查询之间有新的数据被插入，就会导致两次范围查询的结果不一致。

读已提交和可重复读的区别是他的读锁会在查询操作结束之后立刻释放掉，这样，在事务执行过程中，已经查询过的数据是可以被其他事务任意修改的，所以也就会有不可重复读的问题。

读未提交级别下，则完全不会加读锁。这样造成的问题是，由于读操作时不会去申请读锁，所以反而会导致能够读到其他事务上加了写锁的数据，也就会出现脏读的问题。

当然，为了更好的平衡性能与隔离性，还有一些诸如MVCC之类的方案，用额外的存储来实现事务隔离的效果，这些是取巧解决80%问题的方式。

原文地址: http://lichuanyang.top/posts/9775/

kubernetes是什么-实用向教程

2023-01-28 19:06:17

这篇教程不会关注 kubernetes 的部署、架构、实现方式等内部原理，而是完全从一个使用 kubernetes 的开发人员的视角去介绍kubernetes是什么，从而帮助了解如何更好的去利用 kubernetes 的特性。

基本介绍

对于kubernetes是什么，一个比较官方的定义，Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用，简称为k8s.

通俗一些来讲，k8s 的核心理念是以应用为中心，向下屏蔽基础设施的差异，向上通过容器镜像实现应用的标准化，帮助开发人员在仅需关注应用本身，无需考虑部署、容灾、伸缩等运维细节的情况下，开发出大规模、可靠的分布式应用。

优势

如上所述，k8s的核心优势就是降低运维成本，让应用开发人员能够专注于应用本身。具体来讲，包括如下几点：

便捷的部署流程和大规模的复制分发能力：应用提供标准化的容器镜像，之后的部署发布流程都可以做到自动化；应用也无需再做更多的事情就可以实现跨平台、跨区域的部署。
服务自愈能力：自动摘除不健康的节点并做恢复。
敏捷的自动伸缩：根据设定的系统负载，做快速的自动伸缩，实现系统处理能力和成本之间的平衡。

主要概念及实现方式介绍

这篇kubernetes教程的剩余部分会从应用开发人员视角，介绍需要了解的k8s概念，主要包括以下几类：

Pod, service, deployment等基本概念
spec+controller这套基本实现原理
k8s提供给应用的扩展点

spec+controller

这是k8s内部大部分逻辑的实现方式，了解这个逻辑，可以帮助开发人员更好的理解某些特定情况下k8s的行为。

如果翻看k8s的yaml配置，就会发现k8s的大部分组件中都有一个或若干个spec字段，它的含义很好理解，就是对于某个属性的期望值，比如一个服务节点数量的期望值。

controller的作用就是持续监测期望值和实际指标是否一致，不一致时就进行相应的操作进行处理，比如发现节点数不够了，就会启动对应数量的新节点。

这样，无论是上线、扩缩容、还是故障恢复，我们会发现这些逻辑都变得非常清晰，都是触发一下对容器数期望值或实际值的调整，然后让controller去增删节点就可以了。

这套机制是k8s里广泛使用的一个底层设计原则，作用是解开监控和操作逻辑之间的耦合。举个例子，我们在很多情况下都需要触发启动新的节点，包括要做扩容时、部分节点挂了时、要上线时，等等。这些完全没关联的场景如何去触发相同的操作，代码要如何保持整洁呢？k8s的做法就是用一个期望值的概念做中间层，将操作的触发时机和操作本身拆分成独立的逻辑。

了解了这个逻辑，我们可以更容易的理解k8s是怎么工作的。比如基于HPA做自动扩容，就是根据当前的CPU使用情况，和期望的CPU使用量，决定是增加还是减少节点。

Deployment

Deployment 用于指示 k8s 如何创建和更新应用程序，我们通常理解的一个“服务”、“应用”大体上就对应在deployment这一层上。像镜像、内存cpu使用限制、节点数、环境变量等各种配置，都是在deployment上。

Pod

pod比较好理解，就是我们通常理解的一个节点。pod是 k8s 中最小可管理单元。

Service

Service是一个需要着重了解的概念，它是一个抽象层，它选择具备某些特征的 Pod（容器组）并为它们定义一个访问方式。通常的应用场景下，deployment和service是一一对应的，但实际上deployment和service之间并没有必然的联系。

一个请求恰好可以打到某个deployment关联的所有pod上，看起来是一件非常正常的事情。而事实上，这件事情的发生不是由于这些pod通过一个deployment产生，而是因为deployment上配置了一个标签，通过这个deployment生成的pod都获得了这个标签; 同时，另外存在一个service, 设置通过这个标签选择pod, 请求进入的是通过service选择出的一批pod.

探针(probe)和钩子(hook)

k8s提供了一些用于应用扩展的接口，其中就包括probe和hook, 可以帮助应用更好的利用k8s的能力。

k8s提供了 liveness和 readiness 探针，顾名思义，liveness probe的作用是判断应用是否存活，readiness probe的作用是判断应用是否已经启动完毕。

应用可以用http接口等不同形式提供探针，k8s则负责在探测到不同状态时做不同的操作。比如说探测到liveness probe返回状态异常，则可以认为此节点已经丢失，对此节点做删除处理。

hook则支持应用在一些特定阶段插入一些行为，比如preStop hook, 运行应用关闭之前先做一些操作，可以用来做graceful shutdown.

实践思考

通过对本篇kubernetes教程上文列出的概念的了解，相信大家可以从应用开发人员的视角完全理解kubernetes是什么, 也可以大致想象出应用方使用k8s的基本思路：构建标准镜像，暴露出必要的监控数据，剩下的事情都交给k8s来做。

在准确的数据下，k8s可以帮我们做好系统的自愈、扩缩容等操作，而我们要做的是，结合应用场景，尽量给出更加准确的监控数据。

举一些例子，比如说应用提供的liveness探针，如何能尽量确保准确的展示系统的健康状态，某个接口可以访问，某个端口可以调通，能否等价的说明这个应用是否健康。

比如说k8s以cpu、内存等指标来判断系统负载时，这些机器指标能否真实的展现出应用的真实负载，是否有可能连接池、IO等其他瓶颈会在cpu、内存等瓶颈到来之前就达到。

这些都是需要应用方结合应用的实际情况精心设计的。

此外，k8s的设计理念决定了在k8s环境下，“重启”会是一件非常稀松平常的事，像硬件故障、小概率的死循环、不健康的gc, 等不同类型的问题，都可以在k8s的自主重启下实现自愈；自动的扩缩容扩充中，也会经常性的有节点启停。所以说，应用需要让自己的启动流程顺畅一些，避免大量耗时或大量资源消耗。

怎么更科学的用知乎摸鱼

2022-12-28 18:29:01

知乎是个什么样的网站，大家都比较了解，今天我们分享个小工具让我们更开心的使用知乎摸鱼。

之前我在看我自己账号知乎数据的时候，发现一个挺有意思的事情，就是PC端的流量居然有40%以上，这在移动互联网时代，简直是不可想象的。后来也从一些其他渠道了解到，知乎周末、节假日的流量是不如工作日的。

这说明什么呢？上班刷知乎的你，不是一个人。对相当一部分人来说，知乎主要是在上班摸鱼的时候使用的。

知乎这个网站，的确挺适合摸鱼，毕竟以文字内容为主，而且还有相当多的专业性内容，所以工作时上知乎还真的有可能是在查资料。

但是，知乎有些小体验，对摸鱼就不太友好了。比如说图片尺寸太大，还有浏览问题的时候标题浮窗总是会出现，还会很显眼的展示出来。所以，我就写了个简单的油猴脚本，优化了这两个问题，顺便把知乎的logo也给去掉了。

脚本地址：安装地址

大家感兴趣的话欢迎使用。对知乎的使用有什么痛点也欢迎提出来。

原文地址: http://lichuanyang.top/posts/23393/

Mobility修改