建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
譯者 | 陳峻
創(chuàng)新互聯(lián)公司從2013年創(chuàng)立，是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元易門(mén)做網(wǎng)站,已為上家服務(wù),為易門(mén)各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話(huà):028-86922220
審校 | 云昭
本文簡(jiǎn)要展示了如何使用Kubernetes和微服務(wù)架構(gòu)，來(lái)構(gòu)建一個(gè)具有復(fù)雜功能的加密支付應(yīng)用的示例。 Kubernetes已在當(dāng)前各類(lèi)Web應(yīng)用中得到了廣泛使用。那么，開(kāi)發(fā)者想過(guò)它是否可以被應(yīng)用到加密支付類(lèi)型的應(yīng)用開(kāi)發(fā)之中呢？下面，我將向開(kāi)發(fā)者展示如何使用Kubernetes技術(shù)，構(gòu)建通用的區(qū)塊鏈應(yīng)用解決方案的過(guò)程。通過(guò)調(diào)整，該方案也可以被用于其他行業(yè)的應(yīng)用場(chǎng)景中。
涉及到的技術(shù)
該項(xiàng)目在初期雖然預(yù)算有限，但是在被客戶(hù)認(rèn)可后，為了定期向投資人演示新功能的開(kāi)發(fā)進(jìn)展，我們進(jìn)行了持續(xù)迭代。下面便是我們使用到的技術(shù)：
- Node JS（NestJS框架）
- PostgreSQL數(shù)據(jù)庫(kù)
- Kafka JS
- Kubernetes（K8s）+ Helm charts
- Flutter
- React
開(kāi)發(fā)過(guò)程
在第一階段，我們的主要目的是將待開(kāi)發(fā)的應(yīng)用，拆分并創(chuàng)建為如下六個(gè)微服務(wù)：1.管理微服務(wù)2.核心微服務(wù)3.支付微服務(wù)4.郵件和通知服務(wù)5.Cron任務(wù)服務(wù)6.Webhooks微服務(wù)
值得一提的是，這六個(gè)微服務(wù)是專(zhuān)為本區(qū)塊鏈應(yīng)用示例而創(chuàng)建的。如果開(kāi)發(fā)者的應(yīng)用在本質(zhì)上不盡相同，則可以使用相同的技術(shù)，按需設(shè)計(jì)出不同的微服務(wù)。
接著，讓我們來(lái)看看如何在NestJS上構(gòu)建這些微服務(wù)。由于我們需要針對(duì)Kafka消息的代理，來(lái)配置相關(guān)的選項(xiàng)，因此我們?yōu)樗形⒎?wù)的公共模塊和配置，創(chuàng)建了一個(gè)共享的資源文件夾。
1.微服務(wù)的配置選項(xiàng)
import { ClientProviderOptions, Transport } from '@nestjs/microservices';
import CONFIG from '@application-config';
import { ConsumerGroups, ProjectMicroservices } from './microservices.enum';
const { BROKER_HOST, BROKER_PORT } = CONFIG.KAFKA;
export const PRODUCER_CONFIG = (name: ProjectMicroservices): ClientProviderOptions => ({
name,
transport: Transport.KAFKA,
options: {
client: {
brokers: [`${BROKER_HOST}:${BROKER_PORT}`],
},
}
});
export const CONSUMER_CONFIG = (groupId: ConsumerGroups) => ({
transport: Transport.KAFKA,
options: {
client: {
brokers: [`${BROKER_HOST}:${BROKER_PORT}`],
},
consumer: {
groupId
}
}
});左右滑動(dòng)查看完整代碼
讓我們通過(guò)consumer模式，將管理面板的微服務(wù)連接到Kafka上。它將允許我們?nèi)ゲ蹲胶吞幚韥?lái)自各個(gè)主題的事件。
然后，我們通過(guò)如下代碼，使應(yīng)用程序能夠在微服務(wù)的模式下消費(fèi)（使用）事件：
app.connectMicroservice(CONSUMER_CONFIG(ConsumerGroups.ADMIN)); await app.startAllMicroservices();
開(kāi)發(fā)者可能已注意到，consumer的配置中包含了groupId。它會(huì)允許來(lái)自同一組的consumer從主題中獲取事件，并將它們分發(fā)給彼此，以更快地對(duì)其進(jìn)行處理。假設(shè)我們的微服務(wù)能夠接收到事件的速度，快于它處理事件的速度，那么我們便可以通過(guò)自動(dòng)擴(kuò)展以生成額外的pod的方式，來(lái)共享它們之間的負(fù)載，并且讓該過(guò)程的速度翻倍。為此，consumer應(yīng)該被置于組中，并將由擴(kuò)展生成的pod也放在同一組中。在此基礎(chǔ)上，它們將能夠共享加載，而不必處理來(lái)自不同Kafka分區(qū)的相同主題事件。下面，讓我們來(lái)看看如何在NestJS中捕捉和處理Kafka事件：
2.用戶(hù)控制器
import { Controller } from '@nestjs/common';
import { Ctx, KafkaContext, MessagePattern, EventPattern, Payload } from '@nestjs/microservices';
@Controller('consumer')
export class ConsumerController {
@MessagePattern('hero')
readMessage(@Payload() message: any, @Ctx() context: KafkaContext) {
return message;
}
@EventPattern('event-hero')
sendNotif(data) {
console.log(data);
}
}左右滑動(dòng)查看完整代碼
通常，consumer可以在兩種模式下工作：
- EventPattern decorator--接收并處理各種事件，但不返回任何響應(yīng)
- MessagePattern decorator--在處理事件后，將響應(yīng)返回給producer
由于EventPattern不需要額外地包含任何源代碼層，便可提供請(qǐng)求/響應(yīng)功能，因此如果可能的話(huà)，它應(yīng)該被作為首選項(xiàng)。
配置Producer
為了連接Producer，我們需要為負(fù)責(zé)發(fā)送事件的模塊，提供Producer的相關(guān)配置。
1.Producer連接
import { Module } from '@nestjs/common';
import DatabaseModule from '@shared/database/database.module';
import { ClientsModule } from '@nestjs/microservices';
import { ProducerController } from './producer.controller';
import { PRODUCER_CONFIG } from '@shared/microservices/microservices.config';
import { ProjectMicroservices } from '@shared/microservices/microservices.enum';
@Module({
imports: [
DatabaseModule,
ClientsModule.register([PRODUCER_CONFIG(ProjectMicroservices.ADMIN)]),
],
controllers: [ProducerController],
providers: [],
})
export class ProducerModule {}左右滑動(dòng)查看完整代碼
2.基于事件的Producer
import { Controller, Get, Inject } from '@nestjs/common';
import { ClientKafka } from '@nestjs/microservices';
import { ProjectMicroservices } from '@shared/microservices/microservices.enum';
@Controller('producer')
export class ProducerController {
constructor(
@Inject(ProjectMicroservices.ADMIN)
private readonly client: ClientKafka,
) {}
@Get()
async getHello() {
this.client.emit('event-hero', { msg: 'Event Based'});
}
}左右滑動(dòng)查看完整代碼
3.基于請(qǐng)求/響應(yīng)的Producer
import { Controller, Get, Inject } from '@nestjs/common';
import { ClientKafka } from '@nestjs/microservices';
import { ProjectMicroservices } from '@shared/microservices/microservices.enum';
@Controller('producer')
export class ProducerController {
constructor(
@Inject(ProjectMicroservices.ADMIN)
private readonly client: ClientKafka,
) {}
async onModuleInit() {
// Need to subscribe to a topic
// to make the response receiving from Kafka microservice possible
this.client.subscribeToResponseOf('hero');
await this.client.connect();
}
@Get()
async getHello() {
const responseBased = this.client.send('hero', { msg: 'Response Based' });
return responseBased;
}
}左右滑動(dòng)查看完整代碼
每個(gè)微服務(wù)既可以工作在Producer或Consumer模式下，也可以同時(shí)工作在兩種混合模式中。通常，微服務(wù)使用混合模式來(lái)實(shí)現(xiàn)負(fù)載平衡，為主題生成事件，并均勻地使用它們，以及共享各種負(fù)載。
下圖是針對(duì)每個(gè)微服務(wù)的實(shí)現(xiàn)，而進(jìn)行的基于Helm圖表模板的Kubernetes配置。
用Helm圖表表示的admin-API微服務(wù)的組件及其結(jié)構(gòu)
該模板由如下配置文件所組成：
- 部署
- 水平pod自動(dòng)擴(kuò)展(hpa)
- 入口控制器
- 服務(wù)
下面，讓我們來(lái)看看每個(gè)配置文件（并不涉及到Helm模板）。
4.Admin-API部署
apiVersion: apps/v1
kind: Deployment
metadata:
name: admin-api
spec:
replicas: 1
selector:
matchLabels:
app: admin-api
template:
metadata:
labels:
app: admin-api
spec:
containers:
- name: admin-api
image: xxx208926xxx.dkr.ecr.us-east-1.amazonaws.com/project-name/stage/admin-api
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: 250m
memory: 512Mi
ports:
- containerPort: 80
env:
- name: NODE_ENV
value: production
- name: APP_PORT
value: "80"
左右滑動(dòng)查看完整代碼
在真實(shí)的項(xiàng)目部署中，我們可能還需要包含諸如：資源限制、運(yùn)行狀況檢查配置、更新策略等更多細(xì)節(jié)配置。在此，我們僅提供了一個(gè)基本的配置示例。開(kāi)發(fā)者可以根據(jù)手頭項(xiàng)目的實(shí)際情況，按需進(jìn)行擴(kuò)展。
5.Admin-API服務(wù)
---
apiVersion: v1
kind: Service
metadata:
name: admin-api
spec:
selector:
app: admin-api
ports:
- name: admin-api-port
port: 80
targetPort: 80
protocol: TCP
type: NodePort
左右滑動(dòng)查看完整代碼
顯然，我們需要對(duì)外公開(kāi)其服務(wù)，才能使用它。讓我們通過(guò)一個(gè)負(fù)載平衡器，來(lái)公開(kāi)該應(yīng)用程序，并提供SSL的相關(guān)配置，以方便使用安全的HTTPS連接。在此，我們選用時(shí)下最流行的解決方案：AWS負(fù)載平衡控制器，并安裝到集群上。
接著，我們需要使用以下配置，來(lái)創(chuàng)建入口控制器：
6.Admin-API入口控制器
apiVersion: networking.K8s.io/v1
kind: Ingress
metadata:
namespace: default
name: admin-api-ingress
annotations:
alb.ingress.kubernetes.io/load-balancer-name: admin-api-alb
alb.ingress.kubernetes.io/ip-address-type: ipv4
alb.ingress.kubernetes.io/tags: Environment=production,Kind=application
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-2:xxxxxxxx:certificate/xxxxxxxxxx
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS
alb.ingress.kubernetes.io/healthcheck-path: /healthcheck
alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'
alb.ingress.kubernetes.io/ssl-redirect: '443'
alb.ingress.kubernetes.io/group.name: admin-api
spec:
ingressClassName: alb
rules:
- host: example.com
http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: admin-api
port:
number: 80
左右滑動(dòng)查看完整代碼
在應(yīng)用了上述配置以后，我們將能夠創(chuàng)建一個(gè)新的ALB負(fù)載平衡器。同時(shí)，我們需要使用在'host'參數(shù)中提供的名稱(chēng)，來(lái)創(chuàng)建一個(gè)域，進(jìn)而將流量從該host，路由到負(fù)載平衡器上。
7.Admin-API自動(dòng)擴(kuò)展配置
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: admin-api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: admin-api
minReplicas: 1
maxReplicas: 2
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 90
左右滑動(dòng)查看完整代碼
有關(guān)Helm
在我們需要降低K8s基礎(chǔ)設(shè)施的復(fù)雜性時(shí)，Helm是一個(gè)非常實(shí)用的工具。沒(méi)有它，我們則需要在集群運(yùn)行之前，編寫(xiě)多個(gè)yml文件。此外，Helm也能夠協(xié)助我們記住應(yīng)用程序、標(biāo)簽、以及名稱(chēng)等之間的關(guān)系。它的工作原理與包管理器比較類(lèi)似，允許我們創(chuàng)建應(yīng)用程序的模板，并可使用簡(jiǎn)單的命令來(lái)準(zhǔn)備和運(yùn)行它。下面，讓我們來(lái)使用helm制作自己的模板：
1.Admin-API的部署（Helm charts）
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Values.appName }}
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: {{ .Values.appName }}
template:
metadata:
labels:
app: {{ .Values.appName }}
spec:
containers:
- name: {{ .Values.appName }}
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- containerPort: {{ .Values.internalPort }}
{{- with .Values.env }}
env: {{ tpl (. | toYaml) $ | nindent 12 }}
{{- end }}
左右滑動(dòng)查看完整代碼
2.Admin-API的服務(wù)（Helm charts）
apiVersion: v1
kind: Service
metadata:
name: {{ .Values.global.appName }}
spec:
selector:
app: {{ .Values.global.appName }}
ports:
- name: {{ .Values.global.appName }}-port
port: {{ .Values.externalPort }}
targetPort: {{ .Values.internalPort }}
protocol: TCP
type: NodePort
左右滑動(dòng)查看完整代碼
3.Admin-API的入口（Helm charts）
apiVersion: networking.K8s.io/v1
kind: Ingress
metadata:
namespace: default
name: ingress
annotations:
alb.ingress.kubernetes.io/load-balancer-name: {{ .Values.ingress.loadBalancerName }}
alb.ingress.kubernetes.io/ip-address-type: ipv4
alb.ingress.kubernetes.io/tags: {{ .Values.ingress.tags }}
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/certificate-arn: {{ .Values.ingress.certificateArn }}
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS
alb.ingress.kubernetes.io/healthcheck-path: {{ .Values.ingress.healthcheckPath }}
alb.ingress.kubernetes.io/healthcheck-interval-seconds: {{ .Values.ingress.healthcheckIntervalSeconds }}
alb.ingress.kubernetes.io/ssl-redirect: '443'
alb.ingress.kubernetes.io/group.name: {{ .Values.ingress.loadBalancerGroup }}
spec:
ingressClassName: alb
rules:
- host: {{ .Values.adminApi.domain }}
http:
paths:
- path: {{ .Values.adminApi.path }}
pathType: ImplementationSpecific
backend:
service:
name: {{ .Values.adminApi.appName }}
port:
number: {{ .Values.adminApi.externalPort }}
4.Admin-API的自動(dòng)擴(kuò)展配置（Helm charts）
{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: {{ include "ks.fullname" . }}
labels:
{{- include "ks.labels" . | nindent 4 }}
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: {{ include "ks.fullname" . }}
minReplicas: {{ .Values.autoscaling.minReplicas }}
maxReplicas: {{ .Values.autoscaling.maxReplicas }}
metrics:
{{- if .Values.autoscaling.targetCPUUtilizationPercentage }}
- type: Resource
resource:
name: cpu
targetAverageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}
{{- end }}
{{- if .Values.autoscaling.targetMemoryUtilizationPercentage }}
- type: Resource
resource:
name: memory
targetAverageUtilization: {{ .Values.autoscaling.targetMemoryUtilizationPercentage }}
{{- end }}
{{- end }}左右滑動(dòng)查看完整代碼
不同模板的值分別位于“Values.yml”、“Values-dev.yml”和“Values stage.yml”文件中。具體它們中的哪一個(gè)將被使用到，則完全取決于真實(shí)的應(yīng)用環(huán)境。下面，讓我們來(lái)查看針對(duì)dev env（開(kāi)發(fā)環(huán)境）的一些示例值。
5.Admin-API Helm的Values-Stage.yml文件
env: stage
appName: admin-api
domain: admin-api.xxxx.com
path: /*
internalPort: '80'
externalPort: '80'
replicas: 1
image:
repository: xxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/admin-api
pullPolicy: Always
tag: latest
ingress:
loadBalancerName: project-microservices-alb
tags: Environment=stage,Kind=application
certificateArn: arn:aws:acm:us-east-2:xxxxxxxxx:certificate/xxxxxx
healthcheckPath: /healthcheck
healthcheckIntervalSeconds: '15'
loadBalancerGroup: project-microservices
autoscaling:
enabled: false
minReplicas: 1
maxReplicas: 100
targetCPUUtilizationPercentage: 80
env:
- name: NODE_ENV
value: stage
- name: ADMIN_PORT
value: "80"
左右滑動(dòng)查看完整代碼
為了在集群上應(yīng)用相關(guān)的配置，我們需要升級(jí)charts，并重新啟動(dòng)部署。
下面，讓我們?cè)趤?lái)看看負(fù)責(zé)此項(xiàng)操作的GitHub的相關(guān)操作步驟。
6.在GitHub的各項(xiàng)操作中應(yīng)用Helm配置
env: stage
appName: admin-api
domain: admin-api.xxxx.com
path: /*
internalPort: '80'
externalPort: '80'
replicas: 1
image:
repository: xxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/admin-api
pullPolicy: Always
tag: latest
ingress:
loadBalancerName: project-microservices-alb
tags: Environment=stage,Kind=application
certificateArn: arn:aws:acm:us-east-2:xxxxxxxxx:certificate/xxxxxx
healthcheckPath: /healthcheck
healthcheckIntervalSeconds: '15'
loadBalancerGroup: project-microservices
autoscaling:
enabled: false
minReplicas: 1
maxReplicas: 100
targetCPUUtilizationPercentage: 80
env:
- name: NODE_ENV
value: stage
- name: ADMIN_PORT
value: "80"
小結(jié)
綜上所述，我們深入研究了如何在一個(gè)特定的加密支付的案例中，使用Kubernetes來(lái)構(gòu)建微服務(wù)，并最終將代碼示例轉(zhuǎn)換為一個(gè)成熟的區(qū)塊鏈應(yīng)用的過(guò)程。雖然我們跳過(guò)了一些其它步驟和組件，但是前面的源代碼足以向開(kāi)發(fā)者展示和詮釋Kubernetes微服務(wù)是如何構(gòu)建的。
本文標(biāo)題：基于K8s技術(shù)構(gòu)建通用的區(qū)塊鏈方案
分享URL：http://m.5511xx.com/article/cdjhgio.html
