代码地址: https://github.com/yexia553/vue_study/tree/%E9%85%8D%E7%BD%AEvue-router/vue3-notes

这个系列的笔记重点会放在怎么样利用Vue3把项目架设起来并跟后端API互动,不会介绍Vue的基础特性,关于Vue的基础特性可以参考这个视频四个小时带你快速入门Vue,我是看这个入门的,觉得还不错。

路由的简单介绍

这个系列的笔记重点会放在怎么样利用Vue3把项目架设起来并跟后端API互动,不会介绍Vue的基础特性,关于Vue的基础特性可以参考这个视频四个小时带你快速入门Vue,我是看这个入门的,觉得还不错。

代码地址: https://github.com/yexia553/vue_study/tree/%E9%85%8D%E7%BD%AEvue-router/vue3-notes

前言

最近团队里有同事在做把本地产品迁移到SaaS的评估工作,他整理了一些需要评估的内容,我觉得还挺不错的,自己在他基础之上根据自己的经验做了一些增删,在这里作一篇笔记。这里面的内容其实也适用于购买一个新的SaaS服务的checklist。

主要分为服务可用性,SaaS和本地部署的功能对比,性能,安全,运维,数据迁移,与公司其他应用的集成 这几个方面。

服务可用性

python的多任务其实用了很久了,因为刚开始写代码的时候总是看网上说高并发、异步之类的,就觉得很高大上,所以刻意地去学过,后来在实际开发工作有过为了使用而使用,也有过真正因为性能问题而必须要使用。今天想把目前掌握的一些内容记录下来。

其实应该介绍一下网上流传甚广的“Python速度慢”和GIL,但是这两个话题在网上有非常多的文章讨论过,就不想再多写了。

Python多任务其实有多线程、多进程和协程三种实现方法,但是协程一般只在性能要求特别高的情况下使用,并且在实现上相对于多线程和多进程要复杂一些,所以不在这里写,以后单独为协程写一篇笔记。

最近在公司做一个项目,跟以往不同的是,在这个项目中,我有点类似于项目经理的角色(但我并不是项目经理)。换了一个角色,发现要想成功做成一个项目,远不是光有好的技术就可以的。

记录一下最近的感受,主要分为这几个方面:充分沟通、预期管理、协调同事关系、任务分配、超前规划。

下面对每一项单独记录。

去年开始写年终总结,今年照例也写一份

工作和技术学习

先说说工作相关的。

之所以想要写这篇笔记是因为上周我们的监控系统发生了一件我以前遇到的事情,这次虽然没有造成严重后果,但是很值得反思。

先说说发生的事情,也就是背景。

我们的监控是基于Prometheus构建的,然后利用grafana做可视化,都是部署在k8s里面的,这个k8s同时也是业务所在的集群,这应该也是很普遍的做法,而且网上很多教程和博客都是这么写的。

所谓“延迟”其实就是指响应时间,比如一个web页面的响应时间,一个api接口的响应时间等等。

这篇笔记分如何实施和如何使用两部分来讲关于延迟的监控。

笔记中不会写实施的详细的步骤,因为这样的内容网上非常多,更多的是记录在使用中一点感想和建议,如果读者正好也在做类似的事情,可能会在思路上能够提供一点点的帮助

我与监控的缘分

可能真的是与监控这个事情挺有缘分的,从第一份工作的第一个项目开始,就跟监控有关系。
一开始是做ELK,用于数据收集和分析的,后来就利用各种beat和logstash的一些能力尝试做系统监控;后来又配合过另外一位同事基于Zabbix改造公司的监控系统,再后来简单的做过基于Promethues对k8s进行监控;最近一段时间又开始带着构建部门的监控系统,回头一看,发现我工作四年多一点,竟然一共做了4次跟监控相关的事情。
但是每一次做的形式和收获都有一点不太一样。

监控的目的

前面一篇笔记写了一点关于构建监控系统的想法,今天详细记录一下里面提到的关于系统“可用性”的监控。

系统可用性监控主要有三种实施方法: 1. 通过对日志解析和分析做 2. 通过外部黑盒系统做 3. 在开发的阶段就开发相应的功能。下面一个一个具体说一下。

通过日志做可用性监控

Django rest Framework入门 二 :DRF框架初体验中其实已经使用了视图了(book.views里面的代码),而且就是实际开发中最常用的模式,但是那是经过DRF框架高度封装的,代码的可读性不好,而且如果不了解里面的细节,当以后遇到需要定制化的工作时可能就无从下手,这一篇笔记会记录一些我自己认为比较重要切常用的实现细节。

写在前面:
本文后面所有的代码样例中,book.urls里面,以下两段代码只能二选一,使用其中一个的时候必须把另外一个注释掉。

第一段是与ViewSet配置使用的,第二段是与ModelViewSet配置使用的。

Django REST Framework

Django本身是一个前后端不分离的框架,适合很多相对简单的开发需求,但是现在很多场景比较复杂,尤其是前端比较复杂,而现在很多前端框架都很不错,能极大简化前端开发工作,这个时候前后端分离就很有必要了;而且现在一般团队中开发成员也都是前后端分离的,前端专门开发UI,后端专门开发业务逻辑;再加上微服务的流行,后端API化的趋势已经很明显了。
Django REST Framework就是一个基于Django的前后端分离框架,可以将后端的功能封装成API对外提供服务。

手工实现API

枸杞岛东崖绝壁的日出

这是前年去枸杞岛玩的时候拍的一张日出,这是我第一次在海上看日出,非常震撼。

照片是用iPhone8原相机拍的,没有任何滤镜和后期加工。

70%的故障都发生在变更的时候

今天在读《SRE·谷歌运维解密》的时候,有一句话让我感触很深。大致意思如下:一个服务大约70%的故障都发生在变更的时候。

70%这个数字不知道他们怎么得来的,但是从个人作为开发和运维两个角色的经验来看,这句话背后想要表达的观点是正确的:变更是故障的主要来源之一。

其实使用DRF也有一段时间了,一些常用的功能基本没有问题,上周在B站上看到一个DRF的教程,看了一下目录觉得还挺齐全的就看了一遍,发现确实很不错,以下是视频的链接:
https://www.bilibili.com/video/BV1Sz4y1o7E8

这个UP主应该一个培训机构的讲师。

说说优缺点。

今天读《SRE·Google运维解密》中关于监控一节的时候,有一段内容讲到了workaround
或者说临时解决办法可能会带来难以偿还的技术债务的问题,在我自己的工作经历中确实有
过这样的经历,值得思考。

人其实是有惰性的,一旦在发生的问题的时候通过某种简单的方法绕过了根因通过打补
丁的方式“解决”了这个问题,那么在没有明确的激励机制的情况,很多时候就不会愿
意再花时间和精力去从根本上解决这个问题。

以下是书中原文

<!-- more -->

近期部署Prometheus的时候,发现网上竟然很难找到比较好的基于k8s部署的教程,甚至就连helm chart官方repo的教程也很不友好,对于很多参数没有详细的解释,也缺少示例。

推荐两个我觉得还不错的资料地址。

0%