建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 陳峻
創(chuàng)新互聯(lián)公司從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務公司，擁有項目網(wǎng)站設計制作、網(wǎng)站設計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元易門做網(wǎng)站,已為上家服務,為易門各地企業(yè)和個人服務,聯(lián)系電話:028-86922220
審校 | 云昭
本文簡要展示了如何使用Kubernetes和微服務架構(gòu)，來構(gòu)建一個具有復雜功能的加密支付應用的示例。 Kubernetes已在當前各類Web應用中得到了廣泛使用。那么，開發(fā)者想過它是否可以被應用到加密支付類型的應用開發(fā)之中呢？下面，我將向開發(fā)者展示如何使用Kubernetes技術(shù)，構(gòu)建通用的區(qū)塊鏈應用解決方案的過程。通過調(diào)整，該方案也可以被用于其他行業(yè)的應用場景中。
涉及到的技術(shù)
該項目在初期雖然預算有限，但是在被客戶認可后，為了定期向投資人演示新功能的開發(fā)進展，我們進行了持續(xù)迭代。下面便是我們使用到的技術(shù)：
- Node JS（NestJS框架）
- PostgreSQL數(shù)據(jù)庫
- Kafka JS
- Kubernetes（K8s）+ Helm charts
- Flutter
- React
開發(fā)過程
在第一階段，我們的主要目的是將待開發(fā)的應用，拆分并創(chuàng)建為如下六個微服務：1.管理微服務2.核心微服務3.支付微服務4.郵件和通知服務5.Cron任務服務6.Webhooks微服務
值得一提的是，這六個微服務是專為本區(qū)塊鏈應用示例而創(chuàng)建的。如果開發(fā)者的應用在本質(zhì)上不盡相同，則可以使用相同的技術(shù)，按需設計出不同的微服務。
接著，讓我們來看看如何在NestJS上構(gòu)建這些微服務。由于我們需要針對Kafka消息的代理，來配置相關(guān)的選項，因此我們?yōu)樗形⒎盏墓材K和配置，創(chuàng)建了一個共享的資源文件夾。
1.微服務的配置選項
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
}
}
});左右滑動查看完整代碼
讓我們通過consumer模式，將管理面板的微服務連接到Kafka上。它將允許我們?nèi)ゲ蹲胶吞幚韥碜愿鱾€主題的事件。
然后，我們通過如下代碼，使應用程序能夠在微服務的模式下消費（使用）事件：
app.connectMicroservice(CONSUMER_CONFIG(ConsumerGroups.ADMIN)); await app.startAllMicroservices();
開發(fā)者可能已注意到，consumer的配置中包含了groupId。它會允許來自同一組的consumer從主題中獲取事件，并將它們分發(fā)給彼此，以更快地對其進行處理。假設我們的微服務能夠接收到事件的速度，快于它處理事件的速度，那么我們便可以通過自動擴展以生成額外的pod的方式，來共享它們之間的負載，并且讓該過程的速度翻倍。為此，consumer應該被置于組中，并將由擴展生成的pod也放在同一組中。在此基礎(chǔ)上，它們將能夠共享加載，而不必處理來自不同Kafka分區(qū)的相同主題事件。下面，讓我們來看看如何在NestJS中捕捉和處理Kafka事件：
2.用戶控制器
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);
}
}左右滑動查看完整代碼
通常，consumer可以在兩種模式下工作：
- EventPattern decorator--接收并處理各種事件，但不返回任何響應
- MessagePattern decorator--在處理事件后，將響應返回給producer
由于EventPattern不需要額外地包含任何源代碼層，便可提供請求/響應功能，因此如果可能的話，它應該被作為首選項。
配置Producer
為了連接Producer，我們需要為負責發(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 {}左右滑動查看完整代碼
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'});
}
}左右滑動查看完整代碼
3.基于請求/響應的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;
}
}左右滑動查看完整代碼
每個微服務既可以工作在Producer或Consumer模式下，也可以同時工作在兩種混合模式中。通常，微服務使用混合模式來實現(xiàn)負載平衡，為主題生成事件，并均勻地使用它們，以及共享各種負載。
下圖是針對每個微服務的實現(xiàn)，而進行的基于Helm圖表模板的Kubernetes配置。
用Helm圖表表示的admin-API微服務的組件及其結(jié)構(gòu)
該模板由如下配置文件所組成：
- 部署
- 水平pod自動擴展(hpa)
- 入口控制器
- 服務
下面，讓我們來看看每個配置文件（并不涉及到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"
左右滑動查看完整代碼
在真實的項目部署中，我們可能還需要包含諸如：資源限制、運行狀況檢查配置、更新策略等更多細節(jié)配置。在此，我們僅提供了一個基本的配置示例。開發(fā)者可以根據(jù)手頭項目的實際情況，按需進行擴展。
5.Admin-API服務
---
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
左右滑動查看完整代碼
顯然，我們需要對外公開其服務，才能使用它。讓我們通過一個負載平衡器，來公開該應用程序，并提供SSL的相關(guān)配置，以方便使用安全的HTTPS連接。在此，我們選用時下最流行的解決方案：AWS負載平衡控制器，并安裝到集群上。
接著，我們需要使用以下配置，來創(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
左右滑動查看完整代碼
在應用了上述配置以后，我們將能夠創(chuàng)建一個新的ALB負載平衡器。同時，我們需要使用在'host'參數(shù)中提供的名稱，來創(chuàng)建一個域，進而將流量從該host，路由到負載平衡器上。
7.Admin-API自動擴展配置
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
左右滑動查看完整代碼
有關(guān)Helm
在我們需要降低K8s基礎(chǔ)設施的復雜性時，Helm是一個非常實用的工具。沒有它，我們則需要在集群運行之前，編寫多個yml文件。此外，Helm也能夠協(xié)助我們記住應用程序、標簽、以及名稱等之間的關(guān)系。它的工作原理與包管理器比較類似，允許我們創(chuàng)建應用程序的模板，并可使用簡單的命令來準備和運行它。下面，讓我們來使用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 }}
左右滑動查看完整代碼
2.Admin-API的服務（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
左右滑動查看完整代碼
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的自動擴展配置（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 }}左右滑動查看完整代碼
不同模板的值分別位于“Values.yml”、“Values-dev.yml”和“Values stage.yml”文件中。具體它們中的哪一個將被使用到，則完全取決于真實的應用環(huán)境。下面，讓我們來查看針對dev env（開發(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"
左右滑動查看完整代碼
為了在集群上應用相關(guān)的配置，我們需要升級charts，并重新啟動部署。
下面，讓我們在來看看負責此項操作的GitHub的相關(guān)操作步驟。
6.在GitHub的各項操作中應用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é)
綜上所述，我們深入研究了如何在一個特定的加密支付的案例中，使用Kubernetes來構(gòu)建微服務，并最終將代碼示例轉(zhuǎn)換為一個成熟的區(qū)塊鏈應用的過程。雖然我們跳過了一些其它步驟和組件，但是前面的源代碼足以向開發(fā)者展示和詮釋Kubernetes微服務是如何構(gòu)建的。
本文標題：基于K8s技術(shù)構(gòu)建通用的區(qū)塊鏈方案
URL鏈接：http://www.dlmjj.cn/article/cdjhgio.html
