Trang chủ Liên hệ

Microservices là gì?, Các khái niệm chính trong Microservices

CÔNG TY TNHH THIẾT BỊ ĐO LƯỜNG VÀ ĐIỀU KHIỂN 03/04/2023

Microservices là gì ?

Thực tế có nhiều định nghĩa khác nhau đối với Microservices nhưng hiểu theo cách đơn giản thì, microservice là một kiếu kiến trúc phần mềm. Các module trong phần mềm này được chia thành các service rất nhỏ (microservice). Mỗi service sẽ được đặt trên một server riêng -> dễ dàng để nâng cấp và scale ứng dụng.

1. Monolithic Architecture

Các ứng dụng doanh nghiệp ngày nay đang được thiết kế để đáp ứng được số lượng lớn nghiệp vụ kinh doanh. Do đó một ứng dụng phần mềm cần cung cấp hàng trăm chức năng và tất cả các những chức năng như vậy thường được gói gọn trong một ứng dụng nguyên khối duy nhất. ERP, CRM và các hệ thống phần mềm khác nhau là những ví dụ điển hình – chúng được xây dựng dưới dạng nguyên khối với hàng trăm chức năng. Việc triển khai, xử lý sự cố, mở rộng và nâng cấp các ứng dụng như vậy quả là một cơn ác mộng đối với bất kỳ doanh nghiệp nào.

Kiến trúc hướng dịch vụ (service-oriented architecture – SOA) được thiết kế để khắc phục các vấn đề phát sinh từ ứng dụng một khối (monolithic) bằng cách đưa ra khái niệm service. Do đó, với SOA, một ứng dụng sẽ được thiết kế dưới dạng kết hợp các service khác nhau. Khái niệm SOA không có nghĩa là biến từng service thành một khối riêng, nhưng hầu hết các ứng dụng triển khai theo SOA đều có hướng triển khai từng service dưới dạng một khối có cùng thời gian runtime. Vì vậy, tương tự như các ứng dụng một khối, các service này theo thời gian cũng tích lũy nhiều nghiệp vụ và chức năng khác nhau. Sự tăng trưởng này sẽ sớm biến những service đó thành những khối u nguyên khối, không khác gì những ứng dụng một khối thông thường.

Hình 1 cho thấy một ứng dụng phần mềm bán lẻ bao gồm nhiều dịch vụ. Tất cả các service này được deploy trong cùng một ứng dụng runtime. Do đó nó cho thấy một số đặc điểm của một ứng dụng nguyên khối: nó phức tạp, được thiết kế, phát triển và deploy trong cùng một đơn vị duy nhất; nó quá khó để áp dụng các phương pháp phát triển linh hoạt và phân phối nhanh; cập nhật một phần ứng dụng sẽ bắt buộc phải triển khai lại toàn bộ ứng dụng.

Ngoài ra còn một số vấn đề đối với kiến trúc một khối: Nó sẽ khó được scale nếu có xung đột về yêu cầu resource (ví dụ như một service cần nhiều CPU hơn trong khi service khác lại cần nhiều bộ nhớ hơn). Một service không ổn định có thể làm cả ứng dụng bị chết, và thông thường, nó khó có thể đổi mới và áp dụng các công nghệ hay framework mới.

Những đặc điểm này là khởi đầu dẫn đến kiến trúc microservice ra đời. Hãy cùng xem xét cách thức hoạt động của nó.

2. Kiến trúc microservice

Nền tẳng của kiến trúc microservice (MSA) là về việc phát triển một ứng dụng bằng các service nhỏ và độc lập chạy trong tiến trình riêng của chúng. Các service này được phát triển và deploy một cách độc lập.

Hầu hết các định nghĩa về MSA giải thích nó như là một khái niệm kiến trúc tập trung vào việc tách các service sẵn có trong kiến trúc một khối thành một tập hợp các service độc lập. Tuy nhiên thì microservice không chỉ là làm những việc phân chia như thế.

Hãy xem xét điều đó bằng cách nhìn các chức năng trong kiến trúc một khối bằng cách xác định khả năng nghiệp vụ cần có từ ứng dụng – đó là trả lời câu hỏi ứng dụng cần làm gì, có ích hay không? Sau đó những khả năng đó có thể được thực hiện các service độc lập hoàn toàn, đủ tốt và khép kín. Chúng có thể được triển khai trên các stack công nghệ khác nhau, nhưng mỗi service sẽ giải quyết một phạm vi kinh doanh rất cụ thể và hạn chế.

Bằng cách này, kiến trúc hệ thống bán lẻ như hình 1 có thể được mô tả lại như sau:Bây giờ hãy xem xét các nguyên tắc kiến trúc quan trọng của microservice và quan trọng hơn là tập trung vào cách chúng có thể được sử dụng trong thực tế.

3. Thiết kế Microservice: Size, Scope và Capabilities.

Bạn có thể làm một trong hai điều khi nói điều microservice: Một là bạn xây dựng ứng dụng của mình từ đầu và hai là bạn chuyển đổi ứng dụng/service của mình hiện có thành microservice. Dù bằng cách nào, điều quan trọng là bạn phải quyết định đúng kích thước, phạm vi và khả năng của các microservice. Đây có lẽ là điều khó nhất mà bạn cần gặp phải khi thực hiện MSA trong thực tế.

Dưới đây là một vài mối quan tâm chính và quan niệm sai lầm về chúng:

Vậy làm thế nào chúng ta có thể thiết kế service đúng cách trong MSA:

3.1 Hướng dẫn thiết kế microservice

4. Message trong microservice

Trong kiến trúc một khối, các chức năng nghiệp vụ của các component/ bộ xử lý khác nhau sẽ gọi nhau bằng cách sử dụng các lệnh hàm gọi hoặc các method gọi hàm của ngôn ngữ lập trình. Trong SOA, điều này đã được chuyển sang cách request/response các message service có tính lỏng lẻo hơn, chủ yếu dựa trên SOAP với nhiều giao thức khác nhau như HTTP, JMS.

4.1 Tin nhắn đồng bộ (Synchronous Messaging) – REST, Thrift

Đối với tin nhắn đồng bộ ( client yêu cầu phản hồi kịp thời từ các service và thời gian đợi để nhận được nó) trong MSA, REST là lựa chọn dễ nhất vì nó cung cấp một kiểu message đơn giản với các request, respose HTTP. Do đó hầu hết các microservice đều sử dụng HTTP bên cạnh các tài nguyên khác (mỗi chức năng đại diện cho một tài nguyên và các hoạt động sẽ được thực hiện trên các tài nguyên khác).Thift được sử dụng như một thay thế cho REST/HTTP trong đồng bộ tin nhắn.

4.2 Tin nhắn không đồng bộ (Asynchronous) – AMQP, STOMP, MQTT

Đối với một số hoàn cảnh chúng ta bắt buộc phải sử dụng các tin nhắn không đồng bộ ( client không muốn phản hồi ngay lập tức hoặc muốn hoàn toàn không phản hồi). Trong những tình huống này, các giao thức tin nhắn không đồng bộ như AMQP, STOPM hay MQTT được sử dụng phổ biến.

4.3 Message Format – JSON, XML, Thrift, ProtoBuf, Avro

Một yếu tố quan trọng khác là định dạng của message. Các ứng dụng một khối truyền thống sử dụng các định dạng nhị phân phức tạp, còn SOA/Web service lại sử dụng các message dựa trên các định dạng message phức tạp (SOAP) hay schema (xsd). Hầu hết các ứng dụng dựa trên microservice sử dụng các định dạng message dựa trên văn bản đơn giản như JSON hay XML trên HTTP REST API. Trong trường hợp chúng ta cần các định dạng message nhị phân (do message văn bản có thể trở nên dài dòng), microservice có thể tận dụng định dạng message nhị phân như binary Thrift, ProtoBuf hay Avro.

4.4 Service Contracts – Khai báo Service Interface – Swagger, RAML, Thrift IDL

Khi bạn có một nghiệp vụ có thể làm thành một service, bạn sẽ cần làm những bản service contract (đại loại một văn bản mà bạn muốn những client khác gọi đến phải tuân theo những nguyên tắc trong đó để trích xuất được dữ liệu). Trong ứng dụng một khối truyền thống, chúng ta hầu như không cần làm bởi vì các service bên trong có thể gọi nhau qua framework hoặc ngôn ngữ nền tảng. Trong SOA/Web service, WSDL thường được dùng để làm service contract, nhưng WSDL không phải là giải pháp trong một hệ thống microservice dùng REST để giao tiếp giữa các service.

Bởi vì chúng ta xây dựng microservice dựa trên kiến trúc REST nên chúng ta có thể sử dụng các kỹ thuật định nghĩa API trong REST để tạo một service contract. Do đó, chúng ta có thể sẻ dụng Swagger và RAML để định nghĩa service contract.

Đối với các hệ thống không dựa trên HTTP/REST, chẳng hạn như Thrift, chúng ta có thể dùng Interface Definition Languages (IDL) như Thrift IDL.

5. Quản lý dữ liệu phân tán

Trong kiến trúc một khối, ứng dụng lưu trữ dữ liệu trong các cơ sở dữ liệu đơn và tập trung để thực hiện các chức năng/khả năng khác nhau của ứng dụng.

Trong MSA< các chức năng được phân tán trên nhiều microservice và nếu chúng ta sử dụng cùng một cơ sở dữ liệu tập trung thì nó rất khó đảm bảo tính lỏng lẻo giữa các service bởi nếu nếu database schema có sự thay đổi ở một service nào đó có thể sẽ làm chết một vài service khác. Do đó, mỗi service cần phải có cơ sở dữ liệu riêng.

Dưới đây là các khía cạnh chính của việc thực hiện quản lý dữ liệu phân tán trong MSA:

Việc quản lý dữ liệu phân tán sẽ cung cấp cho bạn các service tách rời hoàn toàn và tự do lựa chọn các kỹ thuật quản lý dữ liệu khác nhau (SQL hoặc NoSQL,… các hệ thống quản trị cơ sở dữ liệu khác nhau cho mỗi service). Tuy nhiên, đối với các case studytransaction phức tạp liên quan đến nhiều service, các transaction phải được thực hiện bằng cách sử dụng API được cung cấp từ mỗi service và logic tại client hoặc các tầng trung gian (Gateway).

6. Quản trị phân tán

MSA rất thích hợp để quản trị phân tán. Quản trị trong IT được hiểu là các quy trình đảm bảo việc sử dụng công nghệ hiệu quả và cho phép một tổ chức đạt được mục tiêu của mình. Trong SOA, quản trị SOA hướng dẫn phát triển các service có thể sử dụng lại, thiết lập cách thức các service sẽ được thiết kế, phát triển và cách các service đó thay đổi theo thời gian. Nó thiết lập các thỏa thuận giữa bên cung cấp service và người sử dụng service, nói cho người sử dụng biết những gì họ mong muốn và cho bên cung cấp biết những gì họ bắt buộc phải cung cấp. Quản trị SOA có hai loại quản trị thường được dùng phổ biến:

Vậy quản trị trong microservice có ý nghĩa là gì? Trong MSA, microservice được xây dựng dưới các service độc lập và tách rời hoàn toàn với các nền tảng công nghệ khác nhau. Do đó không cần xác định một tiêu chuẩn chung cho thiết kế và phát triển service. Chúng ta có thể tóm tắt quản trị phân tán của microservice như sau:

7. Service Registry và Service Discovery

Trong MSA, số lượng các service mà bạn cần để làm việc sẽ là khá nhiều. Chúng thay đổi vị trí linh hoạt do tính chất cần phát triển nhanh của microservice. Do đó, bạn cần tìm vị trí của microservice trong suốt thời gian runtime. Giải pháp cho vấn đề này là sử dụng Service Registry.

Service Registry

Service registry là nơi để chứa các metadata của các microservice instances (bao gồm vị trí location, host port,…). Các microservice instance được đăng ký với service registry khi khởi động và sẽ hủy đăng ký khi bị shut down. Các thành phần khác cần tìm thông tin của một microservice nào đó thì sẽ tìm thông qua service registry.

Service Discovery

Để tim các microservice đang hoạt động và vị trí location của nó, chúng ta cần đến cơ chế service discovery. Có 2 loại cơ chế service discovery là client-side discovery và server-side discovery. Chúng ta sẽ xem xét kỹ hơn về các cơ chế này:

8. Deployment

Khi nói đến MSA, việc deploy các service đóng một vai trò quan trọng và có các yêu cầu chính như sau:

Kubernetes là một công cụ có khả năng mở rộng các tính năng của Docker bằng cách cho phép quản lý một cụm (cluster) Linux container dưới dạng một hệ thống duy nhất, quản lý và chạy các Docker container trên nhiều máy chủ, cung cấp các vị trí cùng cấp (co-location) của các container, service discovery và các kiểm soát khác. Như bạn có thể thấy, hầu hết các tính năng này đều rất cần thiết trong hệ thống microservice. Do đó, sử dụng Kubernetes (dựa trên Docker) để triển khai hệ thống microservice đã trở thành một giải pháp mạnh mẽ, đặc biệt là đối với các hệ thống có quy mô lớn.

9. Bảo mật

Bảo mật là một yêu cầu quan trọng và phổ biến khi bạn sử dụng microservice trong thực tế. Trước khi tìm hiểu bảo mật trong microservice, chúng ta sẽ xem xét qua cách mà chúng ta thường triển khai bảo mật ở một ứng dụng một khối.

Vậy thì chúng ta có thể trực tiếp sử dụng lại các nguyên tắc này ở MSA không? Câu trả lời là có, nhưng nó đòi hỏi một component bảo mật được triển khai ở từng service có thể giao tiếp với vùng lưu trữ thông tin user và truy xuất thông tin cần thiết. Đó là một cách giải quyết rất tệ trong bảo mật microservice.

Thay vào đó, chúng ta có thể tận dụng các tiêu chuẩn bảo mật API đang được dùng phổ biến như OAuth 2.0, OpenID Connect để tìm giải pháp tốt hơn cho vấn đề bảo mật. Trước khi đi sâu vào vấn đề đó, trước tiên hãy tóm tắt mục đích của từng tiêu chuẩn và cách chúng ta có thể sử dụng chúng.

Bây giờ, hãy xem cách chúng ta có thể sử dụng các tiêu chuẩn này để bảo mật các service trong ví dụ cửa hàng bán lẻ lúc đầu:

Như đã mô tả trong hình trên, các bước chính cần có liên quan đến việc triển khai bảo mật trong hệ thống microservice là:

10. Inter-Service/Process Communication

Trong MSA, các ứng dụng được xây dựng như một tập hợp các service độc lập. Do đó để biết khi nào cần đến nghiệp vụ nào thì chúng ta cần phải có các cấu trúc giao tiếp giữa các service hay quy trình khác nhau. Từ khi microservice sử dụng các chuẩn giao thức (như HTTP) và các định dạng message (như JSON,…) thì yêu cầu tích hợp với một giao thức khác là yêu cầu tối thiểu khi nhắc đến việc giao tiếp giữa các microservice. Một cách tiếp cận khác trong giao tiếp microservice là sử dụng bus message hoặc cổng gateway với khả năng định tuyến tối thiểu và chỉ hoạt động như một ‘dumb pipe’ không triển khai bất kì nghiệp vụ nào trên gateway. Dựa trên những phương pháp này, chúng ta có một số kiểu giao tiếp như sau:

10.1 Point-to-Point Style – Gọi service trực tiếp

Trong kiểu point-to-point , toàn bộ logic định tuyến message nằm trên mỗi điểm cuối và các service có thể giao tiếp trực tiếp. Mỗi microservice sẽ expose một REST API và một microservice cụ thể hoặc một client bên ngoài có thể gọi một microservice khác thông qua REST API của nó.

Rõ ràng mô hình này hoạt động cho các ứng dụng microservice tương đối đơn giản, nhưng khi số lượng service tăng lên, điều này sẽ trở nên phức tạp vô cùng. Sau tất cả, đó chính là lý do cho việc sử dụng ESB trong triển khai SOA truyền thống, đó là loại bỏ các liên kết tích hợp point-to-point lộn xộn này. Hạn chế của kiểu giao tiếp này được liệt kê như sau:

10.2 API-Gateway Style

Ý tưởng chính đằng sau kiểu API-Gateway là sử dụng một message gateway nhẹ làm điểm vào chính cho tất cả client/consumers và thực hiện các yêu cầu phi chức năng phổ biến ở cấp độ gateway. Nói chung, một API-Gateway cho phép bạn sử dụng API được quản lý qua REST/HTTP. Do đó, bạn có thể expose các business functions của mình được triển khai dưới dạng microservice thông qua API-Gateway dưới dạng một API được quản lý. Trên thực tế, đây là sự kết hợp giữa quản lý MSA và API.

Trong kịch bản kinh doanh bán lẻ ban đầu, như được mô tả trong Hình 11, tất cả các microservice được hiển thị thông qua một API-gateway và đó là điểm vào duy nhất cho tất cả các client. Kiểu API-gateway sẽ đem lại cho bạn những lợi ích sau:

Kiểu API-gateway cũng có thể là mẫu được sử dụng rộng rãi nhất trong hầu hết các triển khai microservice.

10.3 Message Broker Style

Trong các tình huống message không đồng bộ, chẳng hạn như các request một chiều sử dụng hàng đợi queues. Điều đó có nghĩa là một microservice có thể là nguồn cung cấp message và nó có thể gửi các message không đồng bộ đến một queue hoặc topic. Sau đó những microservice xử lý message đó sẽ lấy nguồn từ một queue hoặc topic. Kiểu giao tiếp này sẽ tách biệt nguồn cung message và nơi cần sử dụng message. Nó sử dụng một khu vực trung gian để lưu trữ các message cho đến khi những service cần đến có thể xử lý những message đó. Như vậy, các microservice gửi message sẽ không hề biết những microservice nào sử dụng message.

Giao tiếp giữa consumers/producers được tạo thông qua một message broker dựa trên các tiêu chuẩn message không đồng bộ, chẳng hạn như AMQP, MQTT, v.v.

11. Transactions

Các transaction được hỗ trợ như thế nào trong microservice? Trên thực tế thì đây là một nhiệm vụ phức tạp. Kiến trúc microservice khuyến khích các service không có transaction. Lý do là một service nên hoàn toàn khép kín và chỉ có một nhiệm vụ duy nhất. Do đó, trong hầu hết các trường hợp, transaction chỉ được áp dụng ở phạm vi của các microservice (tức là không phải trên nhiều microservice).

Tuy nhiên, nếu có một yêu cầu bắt buộc là phải có các transaction trên nhiều service, thì các kịch bản như vậy có thể được thực hiện bằng việc bổ sung các “hoạt động bù” ở cấp độ microservice. Có nghĩa là một microservice cụ thể chỉ có một nhiệm vụ và nếu một microservice cụ thể không thực hiện được nhiệm vụ, chúng ta có thể coi đó là một thất bại của toàn bộ microservice đó. Sau đó, tất cả các hoạt động upstream khác phải được hoàn tác bằng cách gọi hoạt động bù tương ứng của các microservice đó.

12. Thiết kế khi gặp lỗi

MSA là một bộ service phân tán và so với thiết kế nguyên khối, nó làm tăng khả năng gặp sự cố ở mỗi cấp độ service. Một microservice cụ thể có thể thất bại do sự cố mạng, không có sẵn tài nguyên cơ bản, v.v. Một microservice không có sẵn hoặc không phản hồi sẽ không được phép làm chết cả ứng dụng. Do đó, bản thân mỗi microservice nên có khả năng chịu lỗi, có thể phục hồi và nhờ đó client sẽ xử lý lỗi một cách mềm mại. Hơn nữa, vì các service có thể thất bại bất cứ lúc nào, điều quan trọng là có thể phát hiện (giám sát theo thời gian thực) các lỗi một cách nhanh chóng và nếu có thể, các service này sẽ tự động khôi phục.

Dưới đây là một số phương pháp xử lý lỗi trong microservice:

Circuit Breaker

Khi bạn gọi đến một service, bạn sẽ muốn cài đặt một thành phần giám sát lỗi với mỗi lần gọi, và khi số lỗi đạt ngưỡng nhất định thì thành phần đó sẽ dừng tất cả các request của service (ngắt mạch). Sau một số lượng request nhất định ở trạng thái mở (mà bạn có thể định cấu hình), hãy thay đổi mạch trở lại trạng thái đóng. Thiết kế này khá hữu ích để tránh tiêu thụ tài nguyên không cần thiết, yêu cầu phản hồi chậm trễ do timeout và cũng cung cấp cho chúng ta cách để giám sát hệ thống (dựa vào trạng thái mạch mở hoạt động).

Bulkhead

Mẫu thiết kế Bulkhead là cách thiết kế để cách ly các thành phần khác nhau trong ứng dụng để khi một service bị lỗi sẽ không ảnh hưởng đến bất kì service nào khác.

Timeout

Mẫu timeout là một cơ chế cho phép bạn ngừng chờ phản hồi từ microservice khi bạn nghĩ rằng nó sẽ không đến. Tại đây, bạn có thể chỉ định khoảng thời gian bạn muốn chờ.

Như vậy, chúng ta sẽ sử dụng các mẫu thiết kế này khi nào và như thế nào? Trong hầu hết các trường hợp thì các mẫu này sẽ được áp dụng ở cấp độ gateway. Điều này có nghĩa là khi microservice không khả dụng hoặc không phản hồi ở cấp độ cổng, chúng ta có thể quyết định có nên gửi yêu cầu tới microservice bằng cách sử dụng circuit breaker hoặc mẫu timeout hay không. Áp dụng theo mẫu bulkhead ở gateway cũng rất quan trọng vì nó là điểm đầu vào duy nhất cho tất cả request của client, do đó, sự thất bại trong một service nhất định sẽ không ảnh hưởng đến việc gọi các service khác.

Ngoài ra, cổng gateway có thể được sử dụng làm trung tâm lưu trữ mà tại đó chúng ta có thể có được trạng thái và giám sát từng service, vì mỗi service đều được gọi thông qua cổng gateway.

13. Microservice trong kiến trúc doanh nghiệp hiện đại

Hình 13 minh họa một kiến ​​trúc IT doanh nghiệp cấp cao. Ở đây, chúng ta đã sử dụng một kiến ​​trúc lai bao gồm cả microservice và các hệ thống hiện có. Có những quyết định thiết kế chính mà bạn cần phải đưa ra khi giới thiệu MSA cho tổ chức của mình:

14. Tích hợp Microservice

Các câu hỏi thường gặp nhất trong microservice là ‘microservice có thể nói chuyện với nhau không?’, ‘làm thế nào để xây dựng các microservice mới bằng cách tận dụng một microservice hiện có?’ hoặc ‘làm thế nào để chúng ta soạn thảo/tích hợp microservice và hình thành các service/solution?’.

Trên thực tế, MSA thúc đẩy xây dựng một microservice với phạm vi kinh doanh hạn chế và tập trung. Do đó, khi nói đến việc xây dựng các giải pháp IT trên MSA, không thể tránh khỏi việc chúng ta phải sử dụng các microservice hiện có. Sự tương tác giữa các microservice có thể được thực hiện theo kiểu point-to-point thông thường. Tuy nhiên, cách tiếp cận đó trở nên khá dễ phá vỡ (với quá nhiều tương tác point-to-point, khó quản lý, duy trì, scale và khắc phục sự cố) khi nói đến các giải pháp microservice. Do đó, chúng ta cần tuân thủ các nguyên tắc tốt nhất về tích hợp các microservices để loại bỏ các nhược điểm của tương tác kiểu point-to-point.

14.1 Phối hợp tại Microservices Layer

Khi bạn phải gọi nhiều microservices để hỗ trợ một yêu cầu business nhất định, bạn có thể xây dựng một microservice khác (một lần nữa giải quyết phạm vi business hạn chế) sẽ điều phối các request service đến các microservices cần thiết và tổng hợp phản hồi cuối cùng và gửi lại cho consumer ban đầu.

Ví dụ, Hình 14 mô tả một kịch bản trong đó chúng ta có một vài microservices là A, B, C và D. Bây giờ chúng tôi muốn đưa ra một chức năng mới đòi hỏi phải gọi microservice A và C một cách tuần tự và cung cấp một phản hồi tổng hợp. Để làm điều này, chúng ta có thể xây dựng một microservice mới (microservice E) và logic phối hợp có chứa dịch vụ gọi A và C được nhúng vào microservice E. Tất cả các yêu cầu của microservice được thực hiện thông qua cổng gateway. Nếu microservice E phải được scale một cách độc lập, điều đó có thể được thực hiện bằng cách scale microservice E, A và C theo yêu cầu.

14.2 Phối hợp tại Gateway Layer

Cách tiếp cận khả thi khác là thực hiện cùng một kịch bản phối hợp bằng cách đưa logic phối hợp đến cấp độ cổng gateway. Trong trường hợp này, chúng ta không phải đưa ra một microservice mới, nhưng sẽ cần một lớp virtual service được lưu trữ trong cổng gateway đảm nhiệm việc điều phối.

Ví dụ, như trong Hình 15, service gọi tới microservice A và C có thể được triển khai bên trong cổng gateway (hầu hết các cài đặt microservice gateway đều hỗ trợ tính năng này).

Khi việc scale business mới được nói đến, chúng ta phải scale quy mô của cổng gateway và microservice A và C. Với điều này, cổng gateway sẽ trở nên hơi nguyên khối vì nó cũng chịu trách nhiệm định tuyến tất cả các microservices requests khác.

14.3 Micro-Integration

Khi chúng ta phải xây dựng các giải pháp tích hợp, thường thì việc sử dụng một máy chủ tập trung có chứa logic tích hợp được xem xét hàng đầu. Khái niệm tích hợp vi mô (micro-integration) là một framework tích hợp nhẹ có thể được sử dụng để xây dựng các giải pháp tích hợp; nó có thể tích hợp microservers và các service/system khác (on-premise hoặc SaaS). Và chúng ta có thể scale chúng tại thời điểm runtime chứ không như phương pháp xây dựng máy chủ tích hợp thông thường, nơi mà chúng ta chỉ có thể scale theo những kịch bản lựa chọn sẵn.

14.4 Choreography Style

Một cách tiếp cận khả thi khác là xây dựng các tương tác giữa các microservices bằng cách sử dụng kiểu message không đồng bộ, chẳng hạn như MQTT hoặc Kafka. Trong trường hợp này, không có thành phần trung tâm nào đảm nhiệm các tương tác service. Các service khác nhau có thể thực hiện message bằng các giao thức messaging protocol.

15. WSO2 Microservices Framework cho Java (WSO2 MSF4J)

Có khá nhiều thư viện và framework để xây dựng microservice, nhưng hầu hết trong số đó không thực sự tuân thủ các nguyên tắc cốt lõi của microservice, chẳng hạn như nhẹ hoặc thân thiện với container.

WSO2 cung cấp một microservice framework nhẹ, nhanh và thân thiện với container.

WSO2 Microservices Framework for Java (WSO2 MSF4J) cung cấp tùy chọn tốt nhất để tạo microservice trong Java với ý định triển khai dựa trên container. Các dịch vụ được phát triển bằng WSO2 MSF4J có thể khởi động chỉ trong vài mili giây trong Docker và có thể dễ dàng tạo Docker image.

16. Tổng kết

Kh i bạn muốn kết hợp MSA trong môi trường IT doanh nghiệp hiện đại ngày nay, các khía cạnh chính bạn cần quan tâm tổng kết lại sau:

Bài viết liên quan