Các chiến lược Mocking microservices: Hướng dẫn MSW vs WireMock

Table of Contents
Nếu bạn đã từng gặp trường hợp một bản dựng CI xanh bị lỗi do API staging của bên thứ ba ngẫu nhiên trả về lỗi 503, bạn sẽ hiểu được nỗi đau của các bài kiểm tra tích hợp không được giả lập.
Việc chọn đúng chiến lược giả lập HTTP là sự khác biệt giữa một bộ kiểm thử đáng tin cậy và một mớ hỗn độn không ổn định mà mọi người đều bỏ qua. Khi so sánh Mock Service Worker (MSW) và WireMock, bạn không chỉ so sánh hai thư viện—bạn đang so sánh hai triết lý hoàn toàn khác nhau: chặn mạng cấp node cho hệ sinh thái frontend/JS so với máy chủ proxy độc lập cho môi trường microservice đa ngôn ngữ.
Vấn đề không ổn định: Tại sao chiến lược giả lập quyết định tốc độ
Các bộ kiểm thử tích hợp truy cập vào các API staging trực tiếp của bên thứ ba là một quả bom hẹn giờ của giới hạn tốc độ, thực thi mạng chậm và thời gian chờ ngẫu nhiên. Nếu bạn muốn một bộ kiểm thử nhanh, có tính xác định mà các kỹ sư thực sự có thể chạy trên máy bay mà không cần WiFi, bạn cần giả lập các dependency bên ngoài của mình.

MSW hoạt động bằng cách chặn các yêu cầu mạng đi ở cấp độ tiến trình Node.js bằng cách sử dụng mô-đun msw/node hoặc trong môi trường trình duyệt bằng cách sử dụng Service Worker API. Vì MSW chặn các cuộc gọi mạng trước khi chúng rời khỏi các socket mạng Node.js, các phản hồi giả lập trả về ngay lập tức mà không đi vào các giao diện mạng TCP/IP vật lý.
WireMock hoạt động như một máy chủ giả lập HTTP độc lập chạy dưới dạng tiến trình JVM hoặc container Docker. Các ứng dụng client thực hiện các cuộc gọi HTTP thực sự qua các socket TCP đến cổng host của WireMock. WireMock đánh giá các payload yêu cầu đến dựa trên các ánh xạ stub JSON đã đăng ký và trả về các phản hồi HTTP đã được cấu hình trước.
// Example: Setting up MSW 2.0 network handlers in a Node.js microservice test
import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';
import { fetchPaymentStatus } from '../src/payment-client';
const handlers = [
http.get('https://api.payments.example.com/v1/charges/:chargeId', ({ params }) => {
const { chargeId } = params;
if (chargeId === 'ch_invalid') {
return HttpResponse.json({ error: 'Charge not found' }, { status: 404 });
}
return HttpResponse.json({
id: chargeId,
amount: 4999,
currency: 'usd',
status: 'succeeded',
}, { status: 200 });
}),
];
const server = setupServer(...handlers);
describe('Payment Service Client', () => {
beforeAll(() => server.listen({ onUnhandledRequest: 'error' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());
it('fetches payment status successfully for valid charge ID', async () => {
const status = await fetchPaymentStatus('ch_9901');
expect(status.amount).toEqual(4999);
expect(status.status).toEqual('succeeded');
});
});
Việc hiểu cơ chế thực thi này làm nổi bật lý do tại sao MSW vượt trội trong các codebase Node.js và TypeScript. MSW chia sẻ cùng ngữ cảnh bộ nhớ JavaScript với trình chạy kiểm thử của bạn, cho phép các tệp spec kiểm tra các đối số gọi trình xử lý giả lập và ghi đè các triển khai giả lập trên cơ sở từng kiểm thử mà không cần phát hành các lệnh REST quản trị.
// Client code verified by MSW network interception
import axios from 'axios';
export async function fetchPaymentStatus(chargeId: string) {
const response = await axios.get(`https://api.payments.example.com/v1/charges/${chargeId}`);
return response.data;
}
Ngược lại, WireMock hoàn toàn không phụ thuộc vào ngôn ngữ trên các stack microservice đa ngôn ngữ. Một container WireMock duy nhất có thể phục vụ các endpoint giả lập cho các microservice Python, Java, Go và Node.js đồng thời bên trong các stack Docker Compose cục bộ.
Ngoài các stub JSON tĩnh đơn giản, các microservice hiện đại yêu cầu các quy trình tương tác có trạng thái, nơi các cuộc gọi API tuần tự thay đổi giá trị phản hồi hạ nguồn. WireMock cung cấp các máy trạng thái kịch bản tích hợp theo dõi trạng thái tương tác trên nhiều cuộc gọi HTTP mà không yêu cầu logic backend ứng dụng tùy chỉnh.
// Stateful WireMock scenario mapping: Tracking state transition from UNPAID to PAID
{
"scenarioName": "Order Payment Process",
"requiredScenarioState": "Started",
"newScenarioState": "Order Placed",
"request": {
"method": "POST",
"url": "/api/v1/orders"
},
"response": {
"status": 201,
"jsonBody": { "orderId": "ord_505", "status": "PENDING" }
}
}
MSW chặn lưu lượng mạng trong Node.js và trình duyệt như thế nào?
MSW đạt được khả năng giả lập mạng độ trễ bằng 0 bằng cách sử dụng các hook chặn mạng cấp thấp thay vì ghi đè thủ công các đối tượng globalThis.fetch hoặc http.request gốc. Trong môi trường Node.js, MSW sử dụng thư viện @mswjs/interceptors để chặn các kết nối socket ở lớp liên kết V8.

Khi mã ứng dụng phát hành một yêu cầu HTTP thông qua Axios, fetch gốc hoặc node-fetch, bộ chặn của MSW sẽ bắt sự kiện yêu cầu đi, so sánh URL với các trình xử lý yêu cầu đã đăng ký và trả về một đối tượng HttpResponse trực tiếp cho người gọi.
// Advanced MSW 2.0 GraphQL and REST handler composition
import { http, graphql, HttpResponse } from 'msw';
export const microserviceHandlers = [
// Intercept REST endpoint
http.post('https://api.inventory.example.com/v1/stock/reserve', async ({ request }) => {
const body = await request.json() as { sku: string; quantity: number };
if (body.quantity > 100) {
return HttpResponse.json({ error: 'Insufficient inventory' }, { status: 422 });
}
return HttpResponse.json({ reserved: true, reservationId: 'res_8812' });
}),
// Intercept GraphQL query
graphql.query('GetCustomerDetails', ({ variables }) => {
const { id } = variables;
return HttpResponse.json({
data: {
customer: {
id,
name: 'Alex Mercer',
email: 'alex.mercer@example.com',
},
},
});
}),
];
Vì MSW sử dụng các đối tượng Fetch API Request và Response tiêu chuẩn trong phiên bản 2.0, các trình xử lý giả lập được viết cho các kiểm thử đơn vị Node.js có thể được sử dụng lại không thay đổi trong Service Workers của môi trường trình duyệt.
| Tính năng | Mock Service Worker (MSW) | WireMock |
|---|---|---|
| Mô hình chặn | Socket V8 trong tiến trình / Service Worker | Máy chủ proxy TCP HTTP độc lập |
| Hệ sinh thái ngôn ngữ | Node.js, TypeScript, Browser JS | Đa ngôn ngữ (JVM, Go, Python, Node, Ruby) |
| Hiệu suất | Ngay lập tức (trả về bộ nhớ <1ms) | Độ trễ thấp (vòng lặp TCP 5ms - 15ms) |
| Hỗ trợ kịch bản có trạng thái | Yêu cầu biến JS trong bộ nhớ | Máy trạng thái kịch bản JSON tích hợp |
| Chi phí container | Không có chi phí container | Yêu cầu JVM hoặc container Docker |
Ma trận so sánh minh họa rằng MSW cung cấp tính tiện dụng cho nhà phát triển vượt trội và tốc độ thô cho các dự án Node.js, trong khi WireMock cung cấp tính linh hoạt trên toàn doanh nghiệp trên các stack microservice đa ngôn ngữ.
// Reusing MSW handlers between Node.js Vitest unit tests and Storybook UI components
import { http, HttpResponse } from 'msw';
export const commonUserHandlers = [
http.get('/api/user', () => {
return HttpResponse.json({ name: 'Jane Doe', role: 'admin' });
}),
];
Việc chia sẻ các định nghĩa giả lập mạng giữa các kiểm thử đơn vị, kiểm thử tích hợp và các câu chuyện thành phần UI giúp loại bỏ nỗ lực bảo trì giả lập trùng lặp giữa các nhóm kỹ thuật.
Ngoài hỗ trợ REST và GraphQL, các ứng dụng front-end hiện đại dựa vào WebSockets để nhận thông báo theo thời gian thực. MSW 2.0 bao gồm khả năng chặn WebSocket thông qua không gian tên ws, cho phép các nhà phát triển giả lập các kênh sự kiện WebSocket hai chiều một cách sạch sẽ.
// MSW 2.0 WebSocket event mocking example
import { ws } from 'msw';
const chatService = ws.link('wss://chat.example.com/socket');
export const websocketHandlers = [
chatService.addEventListener('connection', ({ client }) => {
client.send(JSON.stringify({ type: 'WELCOME', message: 'Connected to mock server' }));
client.addEventListener('message', (event) => {
const data = JSON.parse(event.data as string);
if (data.type === 'PING') {
client.send(JSON.stringify({ type: 'PONG' }));
}
});
}),
];
Cách thiết lập các container WireMock độc lập cho JVM và các bộ đa ngôn ngữ?
Thiết lập các container WireMock độc lập bao gồm việc khai báo các tệp ánh xạ JSON định nghĩa tiêu chí khớp yêu cầu và các mẫu phản hồi HTTP giả lập tương ứng. WireMock kiểm tra phương thức yêu cầu HTTP đến, các mẫu đường dẫn, tham số truy vấn và giá trị tiêu đề.

WireMock có thể được thực thi bằng cách sử dụng các hình ảnh Docker chính thức (wiremock/wiremock:3.5.0), cho phép các nhà phát triển chạy các thiết lập giả lập giống hệt nhau trong môi trường phát triển cục bộ và tích hợp liên tục.
// WireMock JSON mapping file: mappings/get-user-profile.json
{
"request": {
"method": "GET",
"urlPattern": "/api/v1/users/[0-9]+"
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"jsonBody": {
"id": 101,
"username": "developer_user",
"tier": "enterprise",
"status": "active"
},
"fixedDelayMilliseconds": 50
}
}
Đặt các tệp ánh xạ JSON bên trong thư mục mappings/ hướng dẫn WireMock tự động tải các tuyến stub khi khởi động mà không yêu cầu các cuộc gọi quản trị REST thủ công.
# Docker Compose stack integrating WireMock for polyglot microservice integration tests
version: '3.8'
services:
wiremock:
image: wiremock/wiremock:3.5.0
container_name: integration-wiremock
ports:
- "8080:8080"
volumes:
- ./wiremock/mappings:/home/wiremock/mappings
- ./wiremock/__files:/home/wiremock/__files
command: --verbose --enable-stub-cors
order-service:
build: .
environment:
USER_SERVICE_URL: "http://wiremock:8080"
depends_on:
- wiremock
Để cấu hình WireMock theo chương trình bên trong các kiểm thử tích hợp Node.js, có thể sử dụng wiremock-captain hoặc client API REST quản trị Axios gốc để đặt lại các ánh xạ và chèn các stub phản hồi một lần trong thời gian chạy.
// Programmatic WireMock stubbing via Node.js administrative REST API
import axios from 'axios';
export async function registerWireMockStub(wiremockUrl: string) {
await axios.post(`${wiremockUrl}/__admin/mappings`, {
request: {
method: 'POST',
url: '/api/v1/payments',
bodyPatterns: [
{ matchesJsonPath: '$.amount' }
]
},
response: {
status: 201,
jsonBody: { transactionRef: 'tx_772199', status: 'approved' },
},
});
}
export async function resetWireMockMappings(wiremockUrl: string) {
await axios.post(`${wiremockUrl}/__admin/mappings/reset`);
}
WireMock cũng hỗ trợ tạo mẫu phản hồi thời gian chạy bằng cách sử dụng các hàm trợ giúp Handlebars. Khả năng này cho phép các stub WireMock phản hồi lại các tham số yêu cầu, tính toán dấu thời gian hoặc tự động tạo UUID ngẫu nhiên trong các payload nội dung phản hồi.
// WireMock Handlebars response templating mapping
{
"request": {
"method": "POST",
"url": "/api/v1/echo"
},
"response": {
"status": 200,
"jsonBody": {
"receivedAt": "{{now}}",
"requestId": "{{randomValue type='UUID'}}",
"clientName": "{{jsonPath request.body '$.name'}}"
},
"transformers": ["response-template"]
}
}
Các mẫu giả lập thời gian chạy và chèn lỗi là gì?
Kiểm tra khả năng phục hồi của hệ thống yêu cầu xác thực cách các microservice xử lý các lỗi API bên ngoài, thời gian chờ mạng, giới hạn tốc độ và các phản hồi payload bị hỏng. Cả MSW và WireMock đều cung cấp các nguyên thủy gốc để mô phỏng việc chèn lỗi và các kịch bản kỹ thuật hỗn loạn.

Trong MSW, việc chèn lỗi thời gian chạy được thực hiện bằng cách sử dụng các ghi đè trình xử lý mạng một lần (server.use()) bên trong các tệp spec riêng lẻ. Mẫu này thay đổi các phản hồi giả lập cho một xác nhận kiểm thử duy nhất mà không làm ô nhiễm các trường hợp kiểm thử khác trong bộ.
// Example: MSW runtime fault injection simulating 503 service unavailable and network delays
import { setupServer } from 'msw/node';
import { http, HttpResponse, delay } from 'msw';
import { microserviceHandlers } from './handlers';
import { fetchBillingDetails } from '../src/billing-client';
const server = setupServer(...microserviceHandlers);
describe('Billing Service Fault Resilience', () => {
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());
it('handles 503 Service Unavailable gracefully with exponential backoff', async () => {
// Inject temporary 503 error for billing endpoint
server.use(
http.get('https://api.billing.example.com/v1/invoices', () => {
return new HttpResponse(null, { status: 503, statusText: 'Service Unavailable' });
})
);
await expect(fetchBillingDetails()).rejects.toThrow('Billing service unavailable');
});
it('handles high network latency timeout scenarios', async () => {
// Inject 3000ms delay to trigger client HTTP timeout threshold
server.use(
http.get('https://api.billing.example.com/v1/invoices', async () => {
await delay(3000);
return HttpResponse.json({ invoices: [] });
})
);
await expect(fetchBillingDetails({ timeoutMs: 1000 })).rejects.toThrow('Request timed out');
});
});
WireMock hỗ trợ chèn lỗi thông qua thuộc tính phản hồi fault của nó, hỗ trợ các kịch bản lỗi cấp mạng cụ thể như trả về dữ liệu rác (GARBAGE_KEYS), ngắt kết nối (DROP_CHUNK) hoặc đóng kết nối sớm (EMPTY_RESPONSE).
// WireMock fault injection mapping: Connection reset simulation
{
"request": {
"method": "POST",
"url": "/api/v1/orders"
},
"response": {
"fault": "CONNECTION_RESET_BY_PEER"
}
}
Mô phỏng các chế độ lỗi mạng trong quá trình chạy tích hợp liên tục đảm bảo rằng các vòng lặp thử lại microservice, bộ ngắt mạch và trình xử lý bộ nhớ đệm dự phòng hoạt động đáng tin cậy khi các dependency hạ nguồn gặp sự cố.
// Custom circuit breaker implementation verified against MSW fault injection
import axios from 'axios';
export class ResilientApiClient {
private failureCount = 0;
private readonly threshold = 3;
async executeRequest(url: string) {
if (this.failureCount >= this.threshold) {
throw new Error('Circuit breaker open: requests blocked');
}
try {
const response = await axios.get(url);
this.failureCount = 0;
return response.data;
} catch (error) {
this.failureCount++;
throw error;
}
}
}
Các mẫu kiểm thử hỗn loạn có thể được tự động hóa bằng cách cấu hình tỷ lệ chèn lỗi ngẫu nhiên bên trong các trình xử lý MSW. Việc đưa ra mười phần trăm khả năng phản hồi trạng thái 500 xác minh rằng các thư viện client backend xử lý các trục trặc mạng tạm thời mà không làm mất dữ liệu.
// Randomized chaos injection middleware in MSW
export function createChaosHandler(targetUrl: string, errorProbability = 0.1) {
return http.get(targetUrl, () => {
if (Math.random() < errorProbability) {
return new HttpResponse(null, { status: 500, statusText: 'Internal Chaos Error' });
}
return HttpResponse.json({ status: 'ok' });
});
}
Framework giả lập nào phù hợp với kiến trúc Microservices của bạn?
Việc lựa chọn giữa MSW và WireMock phụ thuộc vào sự đa dạng ngôn ngữ lập trình của nhóm bạn, cơ sở hạ tầng trình chạy kiểm thử và các yêu cầu kiến trúc. Cả hai công cụ đều cung cấp các khả năng mạnh mẽ để cô lập các bộ kiểm thử khỏi các dependency bên ngoài không ổn định.
Nếu tổ chức kỹ thuật của bạn chủ yếu xây dựng bằng JavaScript và TypeScript, MSW cung cấp tốc độ thực thi nhanh nhất, tính tiện dụng cho nhà phát triển sạch nhất và chia sẻ gốc các trình xử lý giả lập giữa các kiểm thử đơn vị Node.js và các kiểm thử thành phần trình duyệt front-end.
Nếu tổ chức của bạn vận hành các môi trường microservice đa ngôn ngữ trải rộng trên Java, Python, Go và C#, việc triển khai một stack container WireMock tập trung bên trong Docker Compose và Kubernetes cung cấp các endpoint giả lập nhất quán trên tất cả các codebase của nhóm.
// Calculation helper for evaluating mock execution latency overhead
function estimateSuiteRunTime(
totalSpecs: number,
avgNetworkLatencyMs: number,
parallelWorkers: number
): number {
const totalLatencyMs = (totalSpecs * avgNetworkLatencyMs) / parallelWorkers;
return Math.round(totalLatencyMs / 1000);
}
// MSW in-memory vs WireMock socket latency comparison
const mswSuiteTime = estimateSuiteRunTime(500, 0.5, 4); // ~1 second
const wiremockSuiteTime = estimateSuiteRunTime(500, 12, 4); // ~15 seconds
console.log(`Estimated 500-spec run time with MSW: ${mswSuiteTime}s`);
console.log(`Estimated 500-spec run time with WireMock: ${wiremockSuiteTime}s`);
Kết hợp MSW cho các kiểm thử đơn vị Node.js cục bộ nhanh với WireMock cho các kiểm thử tích hợp đa container mang lại một kiến trúc kiểm thử tối ưu. Với các chiến lược giả lập đáng tin cậy, các nhóm kỹ thuật có thể phát hành các bản cập nhật microservice với sự tự tin hoàn toàn vào độ tin cậy của hệ thống.
Việc thiết lập các hướng dẫn giả lập rõ ràng trong toàn bộ tổ chức kỹ thuật của bạn sẽ ngăn chặn sự xuống cấp của bộ kiểm thử theo thời gian. Việc ghi lại các mẫu trình xử lý giả lập, kiểm tra phạm vi chặn mạng và giữ các stub giả lập phù hợp với các thông số kỹ thuật API sản xuất đảm bảo rằng các kiểm thử tích hợp vẫn chính xác và dễ bảo trì.
Thường xuyên kiểm tra độ trung thực của trình xử lý giả lập so với các thông số kỹ thuật API staging trực tiếp sẽ ngăn chặn sự trôi dạt của giả lập, đảm bảo rằng các phản hồi mô phỏng phản ánh các thay đổi lược đồ backend thực tế. Các nhóm có thể tự động hóa các công cụ xác thực hợp đồng OpenAPI cùng với các stub MSW và WireMock để đảm bảo độ chính xác của giả lập.
Việc thiết lập các kho lưu trữ giả lập được chia sẻ giữa các nhóm phát triển sẽ giảm thiểu các định nghĩa giả lập trùng lặp. Khi lược đồ API thay đổi, việc cập nhật thư viện giả lập trung tâm sẽ tự động cập nhật các kỳ vọng kiểm thử tích hợp trên tất cả các microservice tiêu thụ.
Đánh giá tốc độ phát triển của nhóm trước và sau khi áp dụng các framework giả lập mạng làm nổi bật những lợi ích đáng kể về năng suất. Việc loại bỏ sự phụ thuộc vào tính khả dụng của API staging cho phép các kỹ sư phần mềm phát triển và xác minh các tính năng phức tạp hoàn toàn ngoại tuyến.
Đầu tư vào cơ sở hạ tầng giả lập hoàn chỉnh xây dựng sự tự tin kỹ thuật lâu dài trên các ranh giới microservice. Các nhóm có thể đổi mới nhanh chóng trong khi vẫn duy trì chất lượng phần mềm cao trên mọi bản phát hành sản xuất.
Cấu hình các kiểm tra xác thực giả lập tự động trong các pipeline tích hợp liên tục đảm bảo rằng các stub giả lập vẫn được đồng bộ hóa với các định nghĩa endpoint sản xuất. Các nhóm kỹ thuật có thể xây dựng và kiểm thử microservice nhanh chóng mà không gặp rủi ro thay đổi đột phá hạ nguồn.
Bạn cũng có thể thích
- Kiến trúc AI Agents: Xây dựng hệ thống tự động
- Kiến trúc hướng sự kiện với Kafka
- Truyền dữ liệu thời gian thực với Apache Kafka
- Thiết kế hệ thống: Xây dựng bộ giới hạn tốc độ phân tán
Câu hỏi thường gặp
Sự khác biệt chính giữa MSW và WireMock là gì?
MSW chặn các yêu cầu mạng trong tiến trình ở socket V8 của Node.js hoặc lớp Service Worker của trình duyệt, trả về các phản hồi giả lập với chi phí mạng bằng không. WireMock hoạt động như một máy chủ proxy HTTP độc lập chạy trong các container JVM hoặc Docker mà các ứng dụng client kết nối qua các socket TCP thực.
MSW 2.0 khác với các phiên bản trước như thế nào?
MSW 2.0 áp dụng các nguyên thủy Fetch API tiêu chuẩn (Request, Response, HttpResponse) và cập nhật cú pháp trình xử lý thành http.get() và http.post(). Nó loại bỏ các trừu tượng bộ giải quyết phản hồi tùy chỉnh, cho phép các trình xử lý giả lập chạy giống hệt nhau trong Node.js và các trình duyệt hiện đại.
WireMock có thể được sử dụng cho các dự án không phải Java không?
Có, WireMock có thể chạy dưới dạng một container Docker độc lập hoặc tiến trình JVM, làm cho nó hoàn toàn không phụ thuộc vào ngôn ngữ. Các microservice Python, Go, Node.js và Ruby có thể thực hiện các cuộc gọi HTTP đến các cổng host của WireMock hoặc cấu hình các ánh xạ theo chương trình thông qua API REST quản trị của WireMock.
Làm cách nào để mô phỏng độ trễ mạng trong MSW?
Bạn có thể mô phỏng độ trễ mạng trong MSW bằng cách sử dụng hàm trợ giúp delay() bên trong trình xử lý yêu cầu giả lập của bạn (await delay(1000)). Điều này cho phép kiểm tra cách các ứng dụng client xử lý các phản hồi chậm và ngưỡng thời gian chờ HTTP.
Chèn lỗi WireMock là gì?
Chèn lỗi WireMock cho phép mô phỏng các chế độ lỗi mạng cấp thấp, chẳng hạn như trả về dữ liệu bị lỗi (GARBAGE_KEYS), ngắt kết nối (DROP_CHUNK) hoặc đặt lại các socket TCP (CONNECTION_RESET_BY_PEER), cho phép kiểm thử kỹ thuật hỗn loạn cho bộ ngắt mạch.
MSW có thể giả lập các API GraphQL không?
Có, MSW bao gồm hỗ trợ chặn GraphQL hạng nhất (graphql.query() và graphql.mutation()). MSW kiểm tra tên hoạt động GraphQL và payload yêu cầu để trả về các cấu trúc dữ liệu JSON giả lập một cách liền mạch.
Free In-Browser Developer Tools
Clean AI CLI logs, build cron expressions, decode JWTs, and calculate chmod permissions offline.
Related Articles

Kiểm thử hợp đồng Microservices với Pact & Node.js
Kiểm thử hợp đồng theo hướng người tiêu dùng với Pact trong các microservice Node.js. Cấu hình Pact Broker, xác minh trạng thái nhà cung cấp và can-i-deploy trong CI/CD.
Read more
gRPC vs ConnectRPC: Microservices hiện đại và Protobuf gốc trình duyệt
Đánh giá kiến trúc gRPC vs ConnectRPC trong TypeScript và Go, khám phá streaming HTTP/1.1 vs HTTP/2, client trình duyệt không cần proxy Envoy và độ trễ RPC p99.
Read more
WebAssembly Ngoài Trình Duyệt: Xây Dựng Microservices Hiệu Năng Cao
Khám phá cách sử dụng WebAssembly phía máy chủ với Wasmtime, WasmEdge và Spin để xây dựng các microservices tốc độ gần như native, không phụ thuộc ngôn ngữ và được sandbox về khả năng — với các điểm chuẩn thực tế so với Docker containers.
Read more