微服务拆分规范

一、微服务拆分规范

微服务拆分之后,工程会比较的多,如果没有一定的规范,将会非常混乱,难以维护。

1、高内聚、低耦合

紧密关联的事物应该放在一起,每个服务是针对一个单一职责的业务能力的封装,专注做好一件事情(每次只有一个更改它的理由)。如下图:有四个服务A、B、C、D,但是每个服务职责不单一,A可能在做B的事情,B又在做C的事情,C又同时在做A的事情,通过重新调整,将相关的事物放在一起后,可以减少不必要的服务。

图1,高内聚、低耦合

通用拆分方式:

  1. 先按业务领域拆,如社区、用户、商城、慢病、工单,如果有相同功能需要聚合,则进行下沉(垂直)。
  2. 再按功能定位拆(水平),如商城业务复杂度提高之后可进一步拆分为商品、订单、物流、支付。
  3. 按重要程度拆,区分核心与非核心,如订单核心,订单非核心。

Continue reading "微服务拆分规范"

【转】在阿里,我们如何管理测试环境

前言

阿里的许多实践看似简单,背后却蕴涵着许多思考,譬如测试环境的管理。

互联网产品的服务通常是由Web应用、中间件、数据库和许多后台业务程序组成的,一套运行环境就是一个自成一体的小生态。最基本的运行环境是线上环境,部署产品的正式发布版本,为用户提供持续可靠的服务。

除此以外,还有许多不对外部用户开放的运行环境,用于产品团队日常的开发和验证,统称为测试环境。正式环境的稳定性,除去软件自身的质量因素,主要与运行的主机、网络等基础设施相关,而测试环境的稳定性则更多受到人为因素影响。由于频繁的版本变更,以及部署未经充分验证的代码,测试环境出故障的情况屡见不鲜。

良好的代码提交习惯、适当的变更前检查有助于减少故障的发生,但无法彻底杜绝后患。增加多套测试环境副本能够有效控制故障的影响范围,然而企业的资源终归有限,降低测试环境成本和提高测试环境稳定性成为了矛盾的两面。

在这个领域里,独具匠心的阿里研发效能团队设计了一种服务级复用的虚拟化技术,称为“特性环境”,其巧妙的思路令人赞叹。本文将围绕测试环境管理的话题,聊聊这种具有阿里特色的工作方式。 Continue reading "【转】在阿里,我们如何管理测试环境"

使用migrage指令进行Redis数据迁移

Continue reading "使用migrage指令进行Redis数据迁移"

Go module 如何发布 v2 及以上版本?

用上 go mod 之后,依赖包都是通过版本打 tag 的形式确定版本号。比如 github.com/mnhkahn/gogogo v1.0.9。每次都改动都是在累加低位的版本号,一直这么用也挺安逸的。突然有一天,我的一个底层包需要大改,导致和之前的版本彻底不兼容,这种情况下如何设置版本号,如何能让调用方成功接入?

Go module 版本号

先讲一下 Go 在用的版本号协议semver (Semantic Versioning)。它定义的版本号格式是:

vMAJOR.MINOR.PATCH

  • MAJOR 主版本号,如果有大的版本更新,导致 API 和之前版本不兼容。我们遇到的就是这个问题。
  • MINOR 次版本号,当你做了向下兼容的新 feature。
  • PATCH 修订版本号,当你做了向下兼容的修复 bug fix。
  • v 所有版本号都是 v 开头。

比如我们用的 Go 语言,目前是 1.12.0。它还是 Go 1,每次升级都保证是兼容的,12的版本号是新 feature,而最末尾的版本号是修复。说明当前的版本上了之后还没有修复过问题。

我这次也是搞了一个不兼容的更新,所以需要升级到 v2.0.0。 Continue reading "Go module 如何发布 v2 及以上版本?"

如何同步多个 git 远程仓库

在本地 git 仓库里找到这个文件  .git/config, 内容如下:

改为如下:

合并 2 个 remote 配置

Continue reading "如何同步多个 git 远程仓库"

Make 命令教程

一、Make的概念

Make这个词,英语的意思是"制作"。Make命令直接用了这个意思,就是要做出某个文件。比如,要做出文件a.txt,就可以执行下面的命令。

但是,如果你真的输入这条命令,它并不会起作用。因为Make命令本身并不知道,如何做出a.txt,需要有人告诉它,如何调用其他命令完成这个目标。

比如,假设文件 a.txt 依赖于 b.txt 和 c.txt ,是后面两个文件连接(cat命令)的产物。那么,make 需要知道下面的规则。

也就是说,make a.txt 这条命令的背后,实际上分成两步:第一步,确认 b.txt 和 c.txt 必须已经存在,第二步使用 cat 命令 将这个两个文件合并,输出为新文件。

像这样的规则,都写在一个叫做Makefile的文件中,Make命令依赖这个文件进行构建。Makefile文件也可以写为makefile, 或者用命令行参数指定为其他文件名。

上面代码指定make命令依据rules.txt文件中的规则,进行构建。

总之,make只是一个根据指定的Shell命令进行构建的工具。它的规则很简单,你规定要构建哪个文件、它依赖哪些源文件,当那些文件有变动时,如何重新构建它。 Continue reading "Make 命令教程"

Linux中如何保证数据安全落盘

背景

      在很多IO场景中,我们经常需要确保数据已经安全的写到磁盘上,以便在系统宕机重启之后还能读到这些数据。但是我们都知道,linux系统的IO路径还是很复杂的,分为很多层,每一层都可能会有buffer来加速IO读写。同时,用户态的应用程序和库函数也可能拥有自己的buffer,这又给IO路径增加了一些复杂性。可见,要想保证数据安全的写到磁盘上,并不是简单调一个write/fwrite就可以搞定的。

      那么要怎么做呢?很多人会想到很多办法,比如:fflush()、fsync()、fdatasync()、sync()、open()使用O_DIRECT或O_SYNC标志等。嗯,这些手段(或者某些组合)的确可以保证数据安全的持久化,那么它们之间有什么区别呢?fflush()和fsync()有啥区别?O_DIRECT是啥意思,它可以保证数据安全的持久化吗?O_DIRECT和O_SYNC区别什么?O_SYNC和fsync()呢?fsync能完成msync的功能吗?本文将试图理解、解释这些概念的作用和区别。 Continue reading "Linux中如何保证数据安全落盘"

软件项目版本号的命名规则及格式

版本控制比较普遍的 3 种命名格式 :

一、GNU 风格的版本号命名格式 :
主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]
Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
示例 : 1.2.1, 2.0, 5.0.0 build-13124

二、Windows 风格的版本号命名格式 :
主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]
Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]
示例: 1.21, 2.0

三、.Net Framework 风格的版本号命名格式:
主版本号.子版本号[.编译版本号[.修正版本号]]
Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
版本号由二至四个部分组成:主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的;内部版本号和修订号是可选的,但是如果定义了修订号部分,则内部版本号就是必选的。所有定义的部分都必须是大于或等于 0 的整数。 Continue reading "软件项目版本号的命名规则及格式"