Microservices là gì ?

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

1. Monolithic Architecture

Các ứng dụng doanh nghiệp ngày này đang được phong cách thiết kế để phân phối được số lượng lớn nhiệm vụ kinh doanh thương mại. Do đó một ứng dụng ứng dụng cần cung ứng hàng trăm tính năng và tổng thể những những tính 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à những mạng lưới hệ thống ứng dụng khác nhau là những ví dụ nổi bật – chúng được thiết kế xây dựng dưới dạng nguyên khối với hàng trăm công dụng. Việc tiến hành, xử lý sự cố, lan rộng ra và tăng cấp những ứng dụng như vậy quả là một cơn ác mộng so 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 ứng dụng kinh doanh bán lẻ gồm có nhiều dịch vụ. Tất cả những service này được deploy trong cùng một ứng dụng runtime. Do đó nó cho thấy 1 số ít đặc thù của một ứng dụng nguyên khối : nó phức tạp, được phong cách thiết kế, tăng trưởng và deploy trong cùng một đơn vị chức năng duy nhất ; nó quá khó để vận dụng những giải pháp tăng trưởng linh động và phân phối nhanh ; update một phần ứng dụng sẽ bắt buộc phải tiến hành lại hàng loạt ứng dụng .
Ngoài ra còn một số ít yếu tố so với kiến trúc một khối : Nó sẽ khó được scale nếu có xung đột về nhu yế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 không thay đổi hoàn toàn có thể làm cả ứng dụng bị chết, và thường thì, nó khó hoàn toàn có thể thay đổi và vận dụng những công nghệ tiên tiến hay framework mới .
Những đặc thù này là khởi đầu dẫn đến kiến trúc microservice sinh ra. Hãy cùng xem xét phương pháp hoạt động giải trí 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 tăng trưởng một ứng dụng bằng những 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 tăng trưởng và deploy một cách độc lập .
Hầu hết những định nghĩa về MSA lý giải nó như thể một khái niệm kiến trúc tập trung chuyên sâu vào việc tách những service sẵn có trong kiến trúc một khối thành một tập hợp những service độc lập. Tuy nhiên thì microservice không chỉ là làm những việc phân loại như vậy .
Hãy xem xét điều đó bằng cách nhìn những công dụng trong kiến trúc một khối bằng cách xác lập năng lực nhiệm vụ cần có từ ứng dụng – đó là vấn đáp thắc mắc ứng dụng cần làm gì, có ích hay không ? Sau đó những năng lực đó hoàn toàn có thể được thực thi những service độc lập trọn vẹn, đủ tốt và khép kín. Chúng hoàn toàn có thể được tiến hành trên những stack công nghệ tiên tiến khác nhau, nhưng mỗi service sẽ xử lý một khoanh vùng phạm vi kinh doanh thương mại rất đơn cử và hạn chế .

Bằng cách này, kiến trúc mạng lưới hệ thống kinh doanh nhỏ như hình 1 hoàn toàn có thể được diễn đạt lại như sau : Bây giờ hãy xem xét những nguyên tắc kiến trúc quan trọng của microservice và quan trọng hơn là tập trung chuyên sâu vào cách chúng hoàn toàn có thể được sử dụng trong trong thực tiễn .

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

Bạn hoàn toàn có thể làm một trong hai điều khi nói điều microservice : Một là bạn kiến thiết xây dựng ứng dụng của mình từ đầu và hai là bạn quy đổ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 hành động đúng kích cỡ, khoanh vùng phạm vi và năng lực của những microservice. Đây có lẽ rằng là điều khó nhất mà bạn cần gặp phải khi thực thi MSA trong trong thực tiễn .
Dưới đây là một vài mối chăm sóc chính và ý niệm sai lầm đáng tiếc về chúng :

• Số dòng code (line of code)/ kích thước team (team size) là số liệu tệ hại: Có một số tranh luận về việc quyết định kích thước của microservice dựa trên số dòng code của việc triển khai hoặc team size. Tuy vậy, đây được coi là những số liệu rất không thực tế và tệ hại.
• Micro là một thuật ngữ bị hiểu sai: Nhiều lập trình viên có xu hướng nghĩ rằng họ nên cố làm cho service nhỏ nhất có thể. Đây là một hiểu nhầm, không phải càng nhỏ thì càng tốt.
• Trong bối cảnh web service, các service thường được triển khai ở các mức độ chi tiết khác nhau – từ một vài chức năng đến vài chục chức năng. Việc có các webservice và đặt chúng dưới dạng microservice sẽ không đem lại cho bất kỳ lợi ích nào của MSA.

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

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

• Single Responsibility Priciple (SRP): Mỗi service cần có phạm vi và bị giới hạn về nghiệp vụ cụ thể, không phụ thuộc lẫn nhau. Điều đó giúp cho chúng ta đáp ứng sự phát triển linh hoạt và nhanh chóng trong cung cấp service.
• Trong giai đoạn thiết kế các microservice, chúng ta nên tìm ranh giới của chúng và tùy chỉnh chúng phù hợp với các nghiệp vụ (hay còn biết đến là giới hạn context trong DomainDriven-Design).
• Chắc chắn việc thiết kế microservice đảm bảo sự phát triển và triển khai nhanh chóng, độc lập của service. Bạn nên tập trung vào phạm vi của microservice, không phải là cố làm cho nó nhỏ hơn.
• Thường thì bạn nên bắt đầu với các ranh giới service rộng, sau đó tái cấu trúc cho các ranh giới nhỏ hơn (dựa trên nghiệp vụ) theo thời gian. Trong ví dụ về hệ thống bán lẻ ở trên, bạn có thể thấy nó đã phân chia các chức năng thành 4 microservice khác nhau là inventory, accounting, shipping và store. Chúng đang giải quyết một nghiệp vụ cụ thể và mỗi service đều không phụ thuộc lẫn nhau, đảm bảo phát triển và deploy nhanh chóng.

4. Message trong microservice

Trong kiến trúc một khối, những tính năng nhiệm vụ của những component / bộ giải quyết và xử lý khác nhau sẽ gọi nhau bằng cách sử dụng những lệnh hàm gọi hoặc những method gọi hàm của ngôn từ lập trình. Trong SOA, điều này đã được chuyển sang cách request / response những message service có tính lỏng lẻo hơn, đa phần 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ố ít thực trạng tất cả chúng ta bắt buộc phải sử dụng những tin nhắn không đồng điệu ( client không muốn phản hồi ngay lập tức hoặc muốn trọn vẹn không phản hồi ). Trong những trường hợp này, những giao thức tin nhắn không đồng nhất như AMQP, STOPM hay MQTT được sử dụng phổ cập .

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 lịch sử sử dụng những định dạng nhị phân phức tạp, còn SOA / Web service lại sử dụng những message dựa trên những định dạng message phức tạp ( SOAP ) hay schema ( xsd ). Hầu hết những ứng dụng dựa trên microservice sử dụng những định dạng message dựa trên văn bản đơn thuần như JSON hay XML trên HTTP REST API. Trong trường hợp tất cả chúng ta cần những định dạng message nhị phân ( do message văn bản hoàn toàn có thể trở nên dài dòng ), microservice hoàn toàn 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 nhiệm vụ hoàn toàn 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 tài liệu ). Trong ứng dụng một khối truyền thống lịch sử, tất cả chúng ta phần đông không cần làm do tại những service bên trong hoàn toàn có thể gọi nhau qua framework hoặc ngôn từ 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 mạng lưới hệ thống microservice dùng REST để tiếp xúc giữa những service .
Bởi vì tất cả chúng ta kiến thiết xây dựng microservice dựa trên kiến trúc REST nên tất cả chúng ta hoàn toàn có thể sử dụng những kỹ thuật định nghĩa API trong REST để tạo một service contract. Do đó, tất cả chúng ta hoàn toàn 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à những góc nhìn chính của việc thực thi quản trị tài liệu phân tán trong MSA :

• Mỗi microservice có thể có một cơ sở dữ liệu riêng để duy trì dữ liệu cần thực hiện chức năng nghiệp vụ của nó.
• Một microservice cụ thể chỉ có thể truy cập vào cơ sở dữ liệu riêng của nó, chứ không phải cơ sở dữ liệu của các service khác.
• Trong một số tình huống, bạn có thể phải cập nhật một số cơ sở dữ liệu cho một giao dịch. Trong các trường hợp như vậy, cơ sở dữ liệu của các service khác chỉ được cập nhật thông qua API của nó (không được phép truy cập trực tiếp vào cơ sở dữ liệu).

Việc quản trị tài liệu phân tán sẽ phân phối cho bạn những service tách rời trọn vẹn và tự do lựa chọn những kỹ thuật quản trị tài liệu khác nhau ( SQL hoặc NoSQL, … những mạng lưới hệ thống quản trị cơ sở tài liệu khác nhau cho mỗi service ). Tuy nhiên, so với những case studytransaction phức tạp tương quan đến nhiều service, những transaction phải được thực thi bằng cách sử dụng API được cung ứng từ mỗi service và logic tại client hoặc những 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à những quy trình tiến độ bảo vệ việc sử dụng công nghệ tiên tiến hiệu suất cao và được cho phép một tổ chức triển khai đạt được tiềm năng của mình. Trong SOA, quản trị SOA hướng dẫn tăng trưởng những service hoàn toàn có thể sử dụng lại, thiết lập phương pháp những service sẽ được phong cách thiết kế, tăng trưởng và cách những service đó biến hóa theo thời hạn. Nó thiết lập những thỏa thuận hợp tác giữa bên cung ứng service và người sử dụng service, nói cho người sử dụng biết những gì họ mong ước và cho bên phân phối biết những gì họ bắt buộc phải cung ứng. Quản trị SOA có hai loại quản trị thường được dùng phổ cập :

• Quản trị Design-time: xác định và kiểm soát cách tạo, thiết kế và phát triển service theo policy.
• Quản trị Run-time: xác định khả năng thực thi các policy trong suốt thời gian thi hành.

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

• Các service có thể tự đưa ra những nguyên tắc về thiết kế và cách thực hiện của riêng nó.
• MSA khuyến khích việc chia sẻ các service chung hoặc có thể tái sử dụng.
• Các khía cạnh quản trị run-time như SALs, điều tiết, giám sát, các yêu cầu chung về bảo mật và service discovery sẽ không được triển khi trên mỗi service. Thay vào đó, chúng nên được ở trong các component chuyên dụng (thường ở tầng API-gateway).

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 những metadata của những microservice instances ( gồm có vị trí location, host port, … ). Các microservice instance được ĐK với service registry khi khởi động và sẽ hủy Đ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 trải 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:

• Client-side discovery Theo cách tiếp cận này, client hoặc API-gateway sẽ có được vị trí của một service instance bằng cách truy vấn một service registry.
• Server-side discovery Với phương pháp này, client/API gateway sẽ gửi một request đến một component (ví dụ như một load balancer) chạy trên một location đã biết. Component đó sẽ gọi đến service registry và xác địh vị trí location mà request cần đến.
• Các microservice có thể tận dụng các giải pháp deployment như Kubernetes cho service-side discovery.

8. Deployment

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

• Khả năng deploy/undeploy độc lập đối với các service khác.
• Phải có khả năng scale cho từng service.
• Deploy nhanh chóng.
• Lỗi trong một service sẽ không được làm ảnh hưởng đến bất kỳ service nào khác. Docker(một công cụ mã nguồn mở cho phép các lập trình viên và quản trị viên hệ thống deploy các container trong mỗi trường Linux) cung cấp một cấp tuyệt vời để deploy các service theo các yêu cầu trên. Các ý chính bao gồm:
• Package của service dưới dạng một Docker image.
• Deploy mỗi service instance bằng một container.
• Scale được thực hiện dựa trên việc thay đổi số lượng container instance.
• Build, deploy và khởi động một service sẽ nhanh hơn nhiều khi sử dụng Docker container (so với các máy ảo VM thông thường).

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

9. Bảo mật

Bảo mật là một nhu yếu quan trọng và phổ cập khi bạn sử dụng microservice trong thực tiễn. Trước khi khám phá bảo mật thông tin trong microservice, tất cả chúng ta sẽ xem xét qua cách mà tất cả chúng ta thường tiến hành bảo mật thông tin ở một ứng dụng một khối .

• Trong một ứng dụng nguyên khối điển hình, bảo mật là tìm ra “ai là người gọi”, “người gọi có thể làm gì” và “chúng ta truyền thông tin đó như thế nào”.
• Điều này thường được thực hiện tại một component bảo mật chung, nằm ở đầu chuỗi xử lý yêu cầu và component đó chứa thông tin cần thiết với việc sử dụng vùng lưu trữ người dùng bên dưới.

Vậy thì tất cả chúng ta hoàn toàn có thể trực tiếp sử dụng lại những nguyên tắc này ở MSA không ? Câu vấn đáp là có, nhưng nó yên cầu một component bảo mật thông tin được tiến hành ở từng service hoàn toàn có thể tiếp xúc với vùng tàng trữ thông tin user và truy xuất thông tin thiết yếu. Đó là một cách xử lý rất tệ trong bảo mật thông tin 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.

• OAuth 2.0Là một giao thức ủy quyền truy cập. Client xác thực với một server ủy quyền và nhận được mã token, được gọi là ‘Access token’. Một access token sẽ không có thông tin nào về user/client. Nó chỉ có một tham chiếu đến thông tin user chỉ có thể truy xuất bởi server ủy quyền. Do đó nó còn được gọi là by-reference token và nó đủ an toàn ngay khi trong mỗi trường mạng internet công khai.
• OpenID Connect hoạt động tương tự như OAuth, nhưng ngoài access token, server ủy quyền sẽ phát hành mã token ID có chứa thông tin về người dùng. Điều này thường được triển khai bằng JWT (JSON Web Token) và nó được đăng ký bởi server ủy quyền. Điều này đảm bảo sự tin tưởng giữa server ủy quyền và client. Do đó, JWT còn được gọi là by-value token vì nó chứa thông tin của người dùng và rõ ràng không an toàn khi sử dụng bên ngoài mạng nội bộ.

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ư đã miêu tả trong hình trên, những bước chính cần có tương quan đến việc tiến hành bảo mật thông tin trong mạng lưới hệ thống microservice là :

• Để lại việc xác thực cho OAuth 2.0 và OpenID Connect (server ủy quyền), nhờ vậy microservice sẽ cung cấp quyền truy cập thành công khi ai đó có quyền sử dụng dữ liệu.
• Sử dụng API-gateway trong đó có một entry-point duy nhất cho tất cả các yêu cầu của máy khách.
• Client kết nối với server ủy quyền và nhận access token (by reference token). Sau đó sẽ gửi các access token kèm theo trong mỗi lần request đến API-gateway.
• Token sẽ được giải mã ở gateway – API-gateway trích xuất access token và gửi nó đến server ủy quyền để truy xuất JWT. (by value-token).
• Cổng gateway sẽ dùng mã JWT kèm theo mỗi lần request đến tầng microservice.
• JWT chứa các thông tin cần thiết để lưu trữ các phiên người dùng… Nếu mỗi service đều có thể hiểu một JSON token thì bạn có thể phân phối cơ chế nhận dạng của mình mà cho phép vận chuyển danh tính của người dùng trên toàn hệ thống của bạn.
• Ở mỗi lớp microservice, chúng ta có thể có một component nhỏ để xử lý JWT.

10. Inter-Service/Process Communication

Trong MSA, những ứng dụng được kiến thiết xây dựng như một tập hợp những service độc lập. Do đó để biết khi nào cần đến nhiệm vụ nào thì tất cả chúng ta cần phải có những cấu trúc tiếp xúc giữa những service hay quy trình tiến độ khác nhau. Từ khi microservice sử dụng những chuẩn giao thức ( như HTTP ) và những đị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à nhu yếu tối thiểu khi nhắc đến việc tiếp xúc giữa những microservice. Một cách tiếp cận khác trong tiếp xúc microservice là sử dụng bus message hoặc cổng gateway với năng lực định tuyến tối thiểu và chỉ hoạt động giải trí như một ‘ dumb pipe ’ không tiến hành bất kỳ nhiệm vụ nào trên gateway. Dựa trên những chiêu thức này, tất cả chúng ta có một số ít kiểu tiếp xúc 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 quy mô này hoạt động giải trí cho những ứng dụng microservice tương đối đơn thuầ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 toàn bộ, đó chính là nguyên do cho việc sử dụng ESB trong tiến hành SOA truyền thống lịch sử, đó là vô hiệu những link tích hợp point-to-point lộn xộn này. Hạn chế của kiểu tiếp xúc này được liệt kê như sau :

• Các yêu cầu phi chức năng, chẳng hạn như xác thực người dùng cuối, điều chỉnh, giám sát, v.v … cần phải được thực hiện ở mỗi cấp độ microservice.
• Do việc sao chép các common function, mỗi microservice có thể trở nên phức tạp.
• Không có trung tâm lưu trữ các yêu cầu phi chức năng, như giám sát, truy tìm hoặc bảo mật cần được áp dụng ở mỗi cấp độ service.
• Thông thường kiểu giao tiếp trực tiếp được coi là microservice anti-pattern khi dùng trong các hệ thống microservice quy mô lớn.

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 ngữ cảnh kinh doanh thương mại kinh doanh nhỏ bắt đầu, như được miêu tả trong Hình 11, tổng thể những microservice được hiển thị trải qua một API-gateway và đó là điểm vào duy nhất cho toàn bộ những client. Kiểu API-gateway sẽ đem lại cho bạn những quyền lợi sau :

• Có khả năng cung cấp các khái niệm trừu tượng cần thiết ở cấp độ gateway cho các microservice, ví dụ: thay vì cung cấp API one-size-fits-all, API-gateway có thể expose API khác nhau cho từng khách hàng.
• Định tuyến/chuyển đổi message nhẹ ở cấp độ gateway- bạn có thể thực hiện lọc, định tuyến và chuyển đổi thông báo cơ bản ở gateway layer.
• Nơi tập trung để áp dụng các yêu cầu phi chức năng, như bảo mật, giám sát và điều tiết – thay vì thực hiện các tính năng chung này ở mỗi lớp microservice.
• Với việc sử dụng mẫu API-gateway, microservice sẽ trở nên nhẹ hơn nữa vì tất cả các yêu cầu phi chức năng được thực hiện ở cấp độ gateway.

Kiểu API-gateway cũng hoàn toàn có thể là mẫu được sử dụng thoáng đãng nhất trong hầu hết những tiến hành 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 trải qua một message broker dựa trên những tiêu chuẩn message không đồng điệu, ví dụ điển hình như AMQP, MQTT, v.v.

11. Transactions

Các transaction được tương hỗ như thế nào trong microservice ? Trên trong thực tiễn thì đây là một trách nhiệm phức tạp. Kiến trúc microservice khuyến khích những service không có transaction. Lý do là một service nên trọn vẹn khép kín và chỉ có một trách nhiệm duy nhất. Do đó, trong hầu hết những trường hợp, transaction chỉ được vận dụng ở khoanh vùng phạm vi của những microservice ( tức là không phải trên nhiều microservice ) .
Tuy nhiên, nếu có một nhu yếu bắt buộc là phải có những transaction trên nhiều service, thì những ngữ cảnh như vậy hoàn toàn có thể được triển khai bằng việc bổ trợ những “ hoạt động giải trí bù ” ở Lever microservice. Có nghĩa là một microservice đơn cử chỉ có một trách nhiệm và nếu một microservice đơn cử không triển khai được trách nhiệm, tất cả chúng ta hoàn toàn có thể coi đó là một thất bại của hàng loạt microservice đó. Sau đó, toàn bộ những hoạt động giải trí upstream khác phải được hoàn tác bằng cách gọi hoạt động giải trí bù tương ứng của những microservice đó .

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

MSA là một bộ service phân tán và so với phong cách thiết kế nguyên khối, nó làm tăng năng lực gặp sự cố ở mỗi Lever service. Một microservice đơn cử hoàn toàn 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ó năng lực chịu lỗi, hoàn toàn có thể phục sinh và nhờ đó client sẽ giải quyết và xử lý lỗi một cách quyến rũ. Hơn nữa, vì những service hoàn toàn có thể thất bại bất kỳ khi nào, điều quan trọng là hoàn toàn có thể phát hiện ( giám sát theo thời hạn thực ) những lỗi một cách nhanh gọn và nếu hoàn toàn có thể, những service này sẽ tự động hóa Phục hồi .
Dưới đây là 1 số ít giải pháp giải quyết và xử lý lỗi trong microservice :

Circuit Breaker

Khi bạn gọi đến một service, bạn sẽ muốn thiết lập 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 toàn bộ những 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 hoàn toàn có thể định thông số kỹ thuật ), hãy đổi khác mạch trở lại trạng thái đóng. Thiết kế này khá hữu dụng để tránh tiêu thụ tài nguyên không thiết yếu, nhu yếu phản hồi chậm trễ do timeout và cũng cung ứng cho tất cả chúng ta cách để giám sát mạng lưới hệ thống ( dựa vào trạng thái mạch mở hoạt động giải trí ) .

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 chính sách được 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 hoàn toàn có thể chỉ định khoảng chừng thời hạn 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 hoàn toàn có thể được sử dụng làm TT tàng trữ mà tại đó tất cả chúng ta hoàn toàn có thể có được trạng thái và giám sát từng service, vì mỗi service đều được gọi trải 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, tất cả chúng ta đã sử dụng một kiến ​ ​ trúc lai gồm có cả microservice và những mạng lưới hệ thống hiện có. Có những quyết định hành động phong cách thiết kế chính mà bạn cần phải đưa ra khi ra mắt MSA cho tổ chức triển khai của mình :

• Sử dụng MSA để làm giải pháp bất cứ khi nào cần và cố gắng đạt được toàn bộ sức mạnh mà MSA mang lại.
• Tích hợp doanh nghiệp vẫn là bắt buộc : vì chúng ta sẽ có một cách tiếp cận hỗn hợp, bạn vẫn sẽ cần tích hợp tất cả các hệ thống và dịch vụ nội bộ của mình với việc sử dụng một phần mềm tích hợp, chẳng hạn như ESB.
• Bạn sẽ không thể vứt bỏ hầu hết các hệ thống hiện có, bởi các microservice mới có thể cần phải gọi các hệ thống nguyên khối đó để tạo điều kiện cho các yêu cầu kinh doanh khác nhau.
• Các ESB ‘mới’: Mặc dù phần mềm tích hợp, chẳng hạn như ESB, vẫn có thể cần thiết cho kiến ​​trúc doanh nghiệp hiện đại, thì một tổ chức vẫn nên tìm kiếm phần mềm tích hợp nhẹ, hiệu suất cao và có thể mở rộng thay vì các frameworks tích hợp hạng nặng.
• Quản lý API: microservice có thể được expose thông qua cổng gateway và tất cả các kỹ thuật quản lý API có thể được áp dụng ở lớp đó. Tất cả các yêu cầu khác như bảo mật, điều chỉnh, lưu trữ và giám sát phải được thực hiện ở cổng gateway. Hơn nữa, các service không dựa trên microservice (SOA truyền thống) cũng có thể được expose thông qua cổng API gateway.

14. Tích hợp Microservice

Các câu hỏi thường gặp nhất trong microservice là ‘ microservice hoàn toàn có thể trò chuyện với nhau không ? ’, ‘ làm thế nào để kiến thiết xây dựng những microservice mới bằng cách tận dụng một microservice hiện có ? ’ hoặc ‘ làm thế nào để tất cả chúng ta soạn thảo / tích hợp microservice và hình thành những service / solution ? ’ .
Trên trong thực tiễn, MSA thôi thúc kiến thiết xây dựng một microservice với khoanh vùng phạm vi kinh doanh thương mại hạn chế và tập trung chuyên sâu. Do đó, khi nói đến việc kiến thiết xây dựng những giải pháp IT trên MSA, không hề tránh khỏi việc tất cả chúng ta phải sử dụng những microservice hiện có. Sự tương tác giữa những microservice hoàn toàn có thể được thực thi theo kiểu point-to-point thường thì. 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 trị, duy trì, scale và khắc phục sự cố ) khi nói đến những giải pháp microservice. Do đó, tất cả chúng ta cần tuân thủ những nguyên tắc tốt nhất về tích hợp những microservices để vô hiệu những điểm yếu kém của tương tác kiểu point-to-point .

• Sử dụng một cổng gateway để expose các microservices: Sử dụng một cổng gateway ở trước tất cả các microservices và tất cả consumers chỉ sử dụng các microservices thông qua cổng gateway .
• Không có gọi trực tiếp giữa các microservices: microservice không thể gọi trực tiếp các microservice, tất cả các cuộc gọi phải đi qua cổng gateway.
• Micro-integration thông qua một máy chủ tích hợp.

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

Khi bạn phải gọi nhiều microservices để tương hỗ một nhu yếu business nhất định, bạn hoàn toàn có thể thiết kế xây dựng một microservice khác ( một lần nữa xử lý khoanh vùng phạm vi business hạn chế ) sẽ điều phối những request service đến những microservices thiết yếu và tổng hợp phản hồi sau cuối và gửi lại cho consumer khởi đầu .
Ví dụ, Hình 14 miêu tả một ngữ cảnh trong đó tất cả 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 tính năng mới yên cầu phải gọi microservice A và C một cách tuần tự và phân phối một phản hồi tổng hợp. Để làm điều này, tất cả chúng ta hoàn toàn có thể kiến thiết 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ả những nhu yếu của microservice được triển khai trải qua cổng gateway. Nếu microservice E phải được scale một cách độc lập, điều đó hoàn toàn có thể được thực thi bằng cách scale microservice E, A và C theo nhu yếu .

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

Cách tiếp cận khả thi khác là triển khai cùng một ngữ cảnh phối hợp bằng cách đưa logic phối hợp đến Lever cổng gateway. Trong trường hợp này, tất cả 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 tàng 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 hoàn toàn có thể được tiến hành bên trong cổng gateway ( hầu hết những setup microservice gateway đều tương hỗ tính năng này ) .
Khi việc scale business mới được nói đến, tất cả 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 nghĩa vụ và trách nhiệm định tuyến toàn bộ những microservices requests khác .

14.3 Micro-Integration

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

14.4 Choreography Style

Một cách tiếp cận khả thi khác là kiến thiết xây dựng những tương tác giữa những microservices bằng cách sử dụng kiểu message không đồng điệu, ví dụ điển hình như MQTT hoặc Kafka. Trong trường hợp này, không có thành phần TT nào đảm nhiệm những tương tác service. Các service khác nhau hoàn toàn có thể triển khai message bằng những 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 ứng một microservice framework nhẹ, nhanh và thân thiện với container .
WSO2 Microservices Framework for Java ( WSO2 MSF4J ) phân phối tùy chọn tốt nhất để tạo microservice trong Java với dự tính tiến hành dựa trên container. Các dịch vụ được tăng trưởng bằng WSO2 MSF4J hoàn toàn có thể khởi động chỉ trong vài mili giây trong Docker và hoàn toàn có thể thuận tiện tạo Docker image .

16. Tổng kết

Kh i bạn muốn tích hợp MSA trong thiên nhiên và môi trường IT doanh nghiệp văn minh ngày này, những góc nhìn chính bạn cần chăm sóc tổng kết lại sau :

• Microservice không phải là thuốc chữa bách bệnh – nó không giải quyết tất cả các nhu cầu IT của doanh nghiệp của bạn, vì vậy chúng ta cần sử dụng nó với các kiến ​​trúc hiện có khác.
• Dùng SOA hợp lý.
• Hầu hết các doanh nghiệp sẽ không thể chuyển đổi toàn bộ hệ thống IT doanh nghiệp của họ sang microservice. Thay vào đó, họ sẽ sử dụng microservice để giải quyết một số case studykinh doanh trong đó họ có thể tận dụng sức mạnh của MSA.
• Tích hợp doanh nghiệp sẽ không bao giờ biến mất – điều đó có nghĩa là bạn cần phải có phần mềm tích hợp, chẳng hạn như ESB, để phục vụ cho tất cả các nhu cầu tích hợp doanh nghiệp của bạn.
• Tất cả business functions phải được expose dưới dạng API bằng cách tận dụng các kỹ thuật quản lý API.
• Tương tác giữa các microservices nên được thực hiện qua cổng gateway.
• Việc phối hợp service giữa các microservice có thể được yêu cầu cho một số business và có thể được triển khai bên trong một microservice khác hoặc ở tại lớp gateway.

Source: https://final-blade.com
Category : Kiến thức Internet