去年，我创建了一个清晰架构（Clean Architecture）微服务框架，它功能强大，但有些重。我写了一个系列文章来讲述它，请参阅"清晰架构（Clean Architecture）的Go微服务"。 我还指出了设计中存在的一些缺陷，并讲到希望以后能修复它们。现在我终于有时间对它进行了改造，结果比我预期的还要好。 我所做的改动不大，但效果惊人。主要的项目结构和接口没有变，我在那些文章中写的大部分内容仍然有效。这次升级修复了旧框架中的所有主要问题。现在它几乎拥有了我理想框架中的所有内容。它是一个轻...
-
清晰架构（Clean Architecture）的Go微服务—重大升级
-
事件驱动的微服务-创建第三方库
本篇是我的事件驱动的微服务系列的第三篇，主要讲述如何在Go语言中创建第三方库。如果想要了解总体设计，请看第一篇"事件驱动的微服务-总体设计"。 在Go语言中创建第三方库是为了共享程序，做起来并不困难，不过你需要考虑如下几个方面： 第三方库的对外接口 第三方库的内部结构 如何处理配置参数 如何扩充第三方库 我们用日志做例子讲述如何创建第三方库。Go语言有许多第三方日志库，它们各有优缺点。我在"清晰架构（Clean Architecture）的Go微服务: 日志管理" 中讲到了“ZAP”是迄今为止我...
-
一个可以自我进化的微服务框架
你是否遇到过这样的框架，它非常简单又是轻量级的，很容易上手，然而当你的项目变得复杂的时候它能自我进化成功能强大的重量级框架，而不需要把整个项目重写? 我是从来没见过。 先让我们来看一下项目的生命周期。通常，当一个新项目开始时，我们不知道它能持续多久，所以我们希望它尽可能简单。大多数项目都会在短时间内夭折，所以它们并不需要复杂的框架。然而，其中有一些击中了用户的痛点并受到欢迎，我们就会不断地对它们改进，使它们变得越来越复杂。结果就是原来简单的框架和设计已经远远不能满足需求，剩下的唯一方法就是重写整...
-
一个非侵入的Go事务管理库——工作原理
在上一篇文章“一个非侵入的Go事务管理库——如何使用”中，我讲述了如何使用事务库。有些读者可能读过"清晰架构（Clean Architecture）的Go微服务: 事物管理" ，其中描述了事务管理系统的旧版本。那篇文章和本文之间会有一些重叠。因为大多数人可能还没有读过那篇文章或者即使读了也忘记了它的内容。因此为了照顾多数读者，本文还是从头开始（假设你没有读过前文）。如果你读过，那你可以直接跳过熟悉的部分。 好的事务库对于使用它的应用程序是透明的。在Go的“sql”库中，有两种类型的数据库链接，“...
-
一个非侵入的Go事务管理库——如何使用
在文章"清晰架构（Clean Architecture）的Go微服务: 事物管理"中，我谈到了如何在清晰架构中实现非侵入的事务管理。 它允许你把事务代码与业务逻辑代码分开，并且让你在编写业务逻辑时不必考虑事务。但它也有一些缺点。首先，它是整个清晰框架（Clean Architecture）的一部分，所以你不能抛开框架单独使用它。其次，尽管它对业务逻辑没有侵入，但它对框架有侵入。你需要修改框架的各个层，使其工作，这使他看起来比较复杂。 第三，正如我在文章中提到的，它存在一个依赖泄漏的漏洞。我虽然在...
-
事件驱动的微服务-事件驱动设计
本篇是“事件驱动的微服务”系列的第二篇，主要讲述事件驱动设计。如果想要了解总体设计，请看第一篇"事件驱动的微服务-总体设计" 程序流程 我们通过一个具体的例子来讲解事件驱动设计。 本文中的程序有两个微服务，一个是订单服务（Order Service）， 另一个是支付服务（Payment Service）。用户调用订单服务的用例createOrder（）来创建订单，创建之后的订单暂时还没有支付信息，订单服务然后发布命令（Command）给支付服务，支付服务完成支付，发送支付完成（Payment C...
-
事件驱动的微服务-总体设计
事件驱动的微服务-总体设计 我在"微服务之间的最佳调用方式"中讲到了微服务之间的两种调用方式。微服务刚兴起时，大部分都是RPC的调用模式。我也写了一个RPC的架构，详情参见"清晰架构（Clean Architecture）的Go微服务"。但现在事件驱动的微服务越来越流行，因为大家觉得它是松耦合的。我会写一个新的系列来讲述如何构建事件驱动的微服务。本文是这个系列的第一篇，总体设计。 本文通过一个具体的例子来讲解事件驱动微服务的设计，它包含两个微服务，一个是订单服务（Order），另一个是支付服务（...
-
如何快速高效率地学习Go语言
要想快速高效率地掌握Go语言，关键是要通过不断写代码去训练，熟能生巧。方法是没问题的，但具体的路径呢？就像开车，能不能给个导航？我希望这篇文章能起到一个导航的作用，这里提供的路径，应该对很多人都适合。当然每个人的具体情况不同，因此路径会有差异。你可以对这个路径进行剪裁，得到最适合自己的。 目标（快速，高效率）： 短时间和高效率是这里的关键词。其实只要你每天用Go来编写程序，时间一长，也就掌握了，它不需要任何技巧，大智若愚，实际上是一个不错的办法。但如果你想最快地掌握Go语言，还是需要一些技巧的。...
-
清晰架构（Clean Architecture）的Go微服务
我用Go和gRPC创建了一个微服务项目，并试图找出最好的程序结构，它可以作为我其他项目的模板。我还将程序设计和编程的最佳实践应用于Go Microservice程序，例如清晰架构（Clean Architecture），依赖注入（Dependency Injection），日志记录，错误处理等。我有Java背景，并发现自己在Java和Go之间挣扎，它们之间的编程理念完全不同。我写了一系列关于在项目工作中做出的设计决策和取舍的文章。 阅读这些文章不需要熟悉Go，但如果你有Go基础绝对会有帮助。如果...
-
清晰架构（Clean Architecture）的Go微服务: 编码风格
编码风格在编程中是一个相对乏味的主题，但是合适的编码风格对一个有效的程序员是至关重要的。 它有三个组成部分： 程序结构 （ application layout） 编码规则或风格 命名约定 我已经在清晰架构（Clean Architecture）的Go微服务: 程序结构¹中讨论了程序结构，因此本文将介绍后两点。 编码规则或风格 没有包级别(package level)变量。包级别变量打破了函数封装并使函数有了不确定。我在本程序中遵循了这个规则，唯一的例外是在“容器”包中，因为它负责程序级配置，在...
-
清晰架构（Clean Architecture）的Go微服务: 事物管理
为了支持业务层中的事务，我试图在Go中查找类似Spring的声明式事务管理，但是没找到，所以我决定自己写一个。 事务很容易在Go中实现，但很难做到正确地实现。 需求: 1.将业务逻辑与事务代码分开。在编写业务用例时，开发者应该只需考虑业务逻辑，不需要同时考虑怎样给业务逻辑加事务管理。如果以后需要添加事务支持，你可以在现有业务逻辑的基础上进行简单封装，而无需更改任何其他代码。事务实现细节应该对业务逻辑透明。 2.事务逻辑应该作用于用例层（业务逻辑）不在持久层上。 3.数据服务（数据持久性）层应对事...
-
清晰架构（Clean Architecture）的Go微服务: 依赖注入（Dependency Injection）
在清晰架构（Clean Architecture）中，应用程序的每一层（用例，数据服务和域模型）仅依赖于其他层的接口而不是具体类型。 在运行时，程序容器¹负责创建具体类型并将它们注入到每个函数中，它使用的技术称为依赖注入²。 以下是要求。 容器包的依赖关系: 容器包是唯一依赖于具体类型和许多外部库的包，因为它需要创建具体类型。 本程序中的所有其他软件包主要仅依赖于接口。 外部库可以包括DB和DB连接，gRPC连接，HTTP连接，SMTP服务器，MQ等。 ＃2中提到的具体类型的资源链接只需要创建一...
-
清晰架构（Clean Architecture）的Go微服务: 程序容器（Application Container）
清晰架构（Clean Architecture）的一个理念是隔离程序的框架，使框架不会接管你的应用程序，而是由你决定何时何地使用它们。在本程序中，我特意不在开始时使用任何框架，因此我可以更好地控制程序结构。只有在整个程序结构布局完成之后，我才会考虑用某些库替换本程序的某些组件。这样，引入的框架或第三方库的影响就会被正确的依赖关系所隔离。目前，除了logger，数据库，gRPC和Protobuf（这是无法避免的）之外，我只使用了两个第三方库ozzo-validation¹和YAML²，而其他所有库...
-
清晰架构（Clean Architecture）的Go微服务: 日志管理
良好的日志记录可以提供丰富的日志数据，便于在调试时发现问题，从而大大提高编码效率。 记录器提供的自动化信息越多越好，日志信息也需要以简洁的方式呈现，便于找到重要的数据。 日志需求: 无需修改业务代码即可切换到其他日志库 不需直接依赖任何日志库 整个应用程序只有一个日志库的全局实例，因此你可以在一个位置更改日志配置并将其应用于整个程序。 可以在不修改代码的情况下轻松更改日志记录选项，例如，日志级别 能够在程序运行时动态更改日志级别 资源句柄：为什么日志记录与数据库不同 当应用程序需要处理外部资源时...
-
清晰架构（Clean Architecture）的Go微服务: 设计原则
我最近写了一个Go微服务应用程序，这个程序的设计来自三个灵感： 清晰架构"Clean Architecture"¹ and SOLID (面向对象设计)² 设计 原则³ Spring的容器技术（Spring’s application context）⁴ Go的简洁设计⁵ 特别是 Go的面向对象的设计⁶ 我使用Spring的基于接口的编程和依赖注入（Dependency Injection）来实现Bob Martin的清晰架构（Clean Architecture），并遵循了Go的简单编程风格。...
-
清晰架构（Clean Architecture）的Go微服务: 程序设计
我使用Go和gRPC创建了一个微服务，并将程序设计和编程的最佳实践应用于该项目。 我写了一系列关于在项目工作中做出的设计决策和取舍的文章，此篇是关于程序设计。 程序的设计遵循清晰架构（Clean Architecture）¹。 业务逻辑代码分三层：用例（usecase），域模型（model）和数据服务（dataservice）。 有三个顶级包“usecase”，“model”和“dataservice”，每层一个。 在每个顶级包（模型除外）中只有一个以该包命名的文件。 该文件为每个包定义了外部世...
-
清晰架构（Clean Architecture）的Go微服务: 程序结构
我使用Go和gRPC创建了一个微服务，并试图找出最佳的程序结构，它可以用作我未来程序的模板。 我有Java背景，并发现自己在Java和Go之间挣扎，它们之间的编程理念完全不同。我写了一系列关于在项目工作中做出的设计决策和取舍的文章。 这是其中的第一篇， 是关于程序结构的。 程序结构的资源 Go的标准程序结构的最佳资源可能是Github上的标准Go程序结构¹，但它不适合我的项目。在阅读了Sylvain Wallez的文章²之后，我终于得到了一些关于其背后原因的信息。 Go起初是专为API和网络服务...
-
云原生的不同解释及正确含义
云原生的解释可以说五花八门，本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。 云原生起源 网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念”。我搜索了英文“CloudNative”，阅读了首页的所有文章，里面没有一篇提到“Matt Stine首次提出云原生”，但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书，叫《迁移到云原生架构》，他以前确实在Pivotal公司工作...
-
从代码的视角深入浅出理解DevOps
对于DevOps的理解大家众说纷纭，就连维基百科（Wikipedia）都没有给出一个统一的定义。一般的解释都是从字面上来理解，就是把开发（Development）和运维(Operations)整合到一起，来加速产品从启动到上线的过程，并使之自动化。这个是对DevOps的广义解释，而且大多数人都是认可的。但这个解释太宽泛了，几乎包括了IT的所有内容，使之没有太大意义。 而DevOps是近几年才兴起的（2014年才开始流行），它是对某种项目模式的描述，是有着其特定内涵的。任何项目都可以分成开发和运维...
-
在容器上构建持续部署及最佳实践初探
要想理解持续集成和持续部署，先要了解它的部分组成，以及各个组成部分之间的关系。下面这张图是我见过的最简洁、清晰的持续部署和集成的关系图。 图片来源 持续部署： 如图所示，开发的流程是这样的：程序员从源码库（Source Control）中下载源代码，编写程序，完成后提交代码到源码库，持续集成（Continuous Integration）工具从源码库中下载源代码，编译源代码，然后提交到运行库（Repository），然后持续交付（Continuous Delivery）工具从运行库（Reposi...
-
在k8s上安装Jenkins及常见问题
持续集成和部署是DevOps的重要组成部分，Jenkins是一款非常流行的持续集成和部署工具，最近试验了一下Jenkins，发现它是我一段时间以来用过的工具中最复杂的。一个可能的原因是它需要与各种其它工具集成才能完成任务，而集成的方法又各不相同。在这些工具中，Docker是最简单的，真的非常好用。K8s比较复杂，开始要花些时间熟悉，但它的整体设计十分合理，一旦搞清核心概念，掌握脉络之后，就非常顺利。它的命令格式即规范又统一，使得有些命令自己都能猜出来，这就是好的设计带来的福利。。但Jenkins...
-
如何把应用程序迁移到k8s
程序部署环境的容器化已经是大势所趋，微服务为容器化提供了广阔的应用舞台，k8s已经把Docker纳入为它的底层支撑容器引擎，一统江湖，成为了容器技术事实上的标准。一般的应用程序是不能直接拿来部署到容器上的，需要经过一些修改才能移植到k8s上。那么这些改动包括哪些内容呢？ 它主要有两个部分: 第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，...
-
创建优化的Go镜像文件以及踩过的坑
在Docker上创建Go镜像文件并不困难，但建立的文件很大，接近1G，使用起来不太方便。Docker镜像的一个主要难题就是如何优化，创建小的镜像。我们可以用多级构建的方法来创建Docker镜像文件，它也不复杂。但由于使用这种方法时，需要用简版的Linux（Alpine），它带来了一系列的问题。本文讲述如何解决这些问题并成功创建优化的Go镜像文件，优化之后只有14M。 单级构建： 我们用一个Go程序作为例子来展示如何创建Go镜像。下面就是这个程序的目录结构。 Go程序的具体内容并不重要，只要能运行...
-
Go微服务容错与韧性(Service Resilience)
Service Resilience是指当服务的的运行环境出现了问题，例如网络故障或服务过载或某些微服务宕机的情况下，程序仍能够提供部分或大部分服务，这时我们就说服务的韧性很强。它是微服务中很重要的一部分内容，并被广泛讨论。它是衡量服务质量的一个重要指标。Service Resilience从内容上讲翻译成“容错”可能更接近, 但“容错”英文是“Fault Tolerance”，它的含义与“Service Resilience”是不同的。因此我觉得翻译成“服务韧性“比较合适。服务韧性在微服务体系...
-
Go微服务全链路跟踪详解
在微服务架构中，调用链是漫长而复杂的，要了解其中的每个环节及其性能，你需要全链路跟踪。 它的原理很简单，你可以在每个请求开始时生成一个唯一的ID，并将其传递到整个调用链。 该ID称为CorrelationID¹，你可以用它来跟踪整个请求并获得各个调用环节的性能指标。简单来说有两个问题需要解决。第一，如何在应用程序内部传递ID; 第二，当你需要调用另一个微服务时，如何通过网络传递ID。 什么是OpenTracing? 现在有许多开源的分布式跟踪库可供选择，其中最受欢迎的库可能是Zipkin²和Ja...
-
微服务之间的最佳调用方式
在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地. 耦合的种类：我们总在谈耦合，那么耦合到底意味着什么呢？ 时间耦合：客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。 容量耦合：客户端和服...
管理员
-
jfeng45 创建者
