Các tình huống của kiến trúc microservice

Kiến trúc phần mềm doanh nghiệp luôn phát triển với các phong cách kiến trúc mới do sự thay đổi mô hình trong bối cảnh của một thời đại công nghệ và  với mong muốn tìm ra những cách tốt hơn để xây dựng các ứng dụng một cách nhanh chóng với độ ổn định cao và đáng tin cậy

Kiến trúc microservices đã được ứng dụng rộng rãi cho phép bạn xây dựng các ứng dụng phần mềm với tốc độ nhanh và độ an toàn cao. Nó thúc đẩy việc xây dựng một hệ thống phần mềm như một tập hợp các service độc lập (được phát triển, triển khai, nâng cấp và bảo trì một cách độc lập) ít phụ thuộc chặt chẽ với nhau. Các service này tạo thành một ứng dụng phần mềm duy nhất bằng cách tích hợp tất cả các service đó.

Trong chương này, chúng ta cùng tìm hiểu microservices là gì, các đặc điểm của microservices với các ví dụ trong thực tế và những ưu và nhược điểm của microservices trong bối cảnh ứng dụng vào các phần mềm quản trị doanh nghiệp.

Bối cảnh của microservice

Khám phá sự phát triển của kiến trúc phần mềm doanh nghiệp từ các ứng dụng nguyên khối (monolithic) đến microservices là một cách tuyệt vời để hiểu các nguyên nhân và đặc điểm chính của microservices. Hãy bắt đầu cuộc thảo luận của chúng ta với các ứng dụng nguyên khối

Từ monolithic đến microservices

Các ứng dụng phần mềm doanh nghiệp được thiết kế để hỗ trợ nhiều yêu cầu về nghiệp vụ trong quá trình sản xuất hoặc kinh doanh. Trong phong cách kiến trúc nguyên khối, tất cả các chức năng, nghiệp vụ, được dồn vào một ứng dụng nguyên khối duy nhất và được xây dựng như một đơn vị duy nhất

Toàn bộ hệ thống quản lý bán hàng là tập hợp của một số module (phân hệ), chẳng hạn như quản lý đơn hàng, thanh toán, quản lý sản phẩm, v.v. Mỗi thành phần này cung cấp một loạt các chức năng về mặt nghiệp vụ. Việc thêm hoặc sửa đổi một chức năng cho một module là cực kỳ tốn kém do bản chất nguyên khối của nó. Ngoài ra, với đặc thù quản lý kinh doanh ở mức tổng thể, các thành phần này phải giao tiếp với nhau. Giao tiếp giữa các thành phần này thường được xây dựng dựa trên các giao thức và tiêu chuẩn, và chúng dựa trên nguyên tắc giao tiếp point-to-point. Do đó, việc sửa đổi hoặc thay thế một thành phần nhất định cũng khá phức tạp. Ví dụ: nếu doanh nghiệp bán lẻ muốn chuyển sang một hệ thống quản lý đơn hàng mới trong khi vẫn giữ phần còn lại, làm như vậy sẽ đòi hỏi phải thay đổi khá nhiều đối với các thành phần hiện có khác

Chúng ta có thể khái quát các đặc điểm chung của ứng dụng nguyên khối như sau:

• Được thiết kế, phát triển và triển khai như một đơn vị (một khối) duy nhất
• Quá phức tạp đối với hầu hết các trường hợp về nghiệp vụ trong thực tế, điều này dẫn đến cơn ác mộng trong việc bảo trì, nâng cấp và thêm các tính năng mới.
• Thật khó để áp dụng các phương pháp quản lý và phát triển phần mềm như Agile. Vì ứng dụng phải được xây dựng như một đơn vị duy nhất, nên hầu hết các tính năng mà nó cung cấp không thể có vòng đời riêng của chúng.
• Bạn phải triển khai lại toàn bộ ứng dụng để cập nhật bất kỳ tính năng nào của nó
• Khi ứng dụng nguyên khối phát triển, có thể mất nhiều thời gian hơn để khởi động, điều này làm tăng thêm chi phí tổng thể.
• Nó phải được mở rộng quy mô như một ứng dụng duy nhất và rất khó mở rộng quy mô với các yêu cầu tài nguyên xung đột. (Ví dụ: vì một ứng dụng nguyên khối cung cấp nhiều tính năng về mặt nghiệp vụ, một tính năng có thể yêu cầu nhiều CPU hơn trong khi một tính năng khác yêu cầu nhiều bộ nhớ hơn. Thật khó để đáp ứng nhu cầu của toàn bộ các tính năng này.)
• Một tính năng không ổn định có thể dẫn đến toàn bộ hệ thống bị lỗi
• Rất khó để áp dụng các công nghệ và framework mới, vì tất cả các chức năng phải xây dựng trên các công nghệ / framework đồng nhất. (Ví dụ: nếu bạn đang sử dụng Java, tất cả các dự án mới, tính năng mới phải thực hiện code với Java, ngay cả khi đó là ngôn ngữ thay thế Java tốt hơn.)

Như một giải pháp cho một số hạn chế của kiến trúc ứng dụng nguyên khối, Kiến trúc hướng services - Service Oriented Architecture (SOA) và Enterprise Service Bus (ESB) đã xuất hiện

SOA và ESB

SOA cố gắng chống lại những thách thức của các kiến trúc nguyên khối lớn bằng cách tách các chức năng của các ứng dụng nguyên khối thành các thực thể có thể tái sử dụng, được kết hợp với nhau và được gọi là services. Các services này có thể gọi lẫn nhau thông qua network.

• Service là sự triển khai khép kín của một chức năng nghiệp vụ được xác định rõ ràng có thể truy cập được qua mạng. Các ứng dụng trong SOA được xây dựng dựa trên các service
• Service là các phần mềm có giao diện (interface) được xác định rõ ràng, không phụ thuộc vào việc triển khai. Một khía cạnh quan trọng của SOA là sự tách biệt của giao diện dịch vụ (service interface) khỏi việc triển khai nó (service implement)
• Các thành phần sử dụng các services chỉ quan tâm đến giao diện dịch vụ (service interface) và không quan tâm đến việc thực hiện của service đó
• Các service là khép kín (thực hiện các nhiệm vụ được xác định trước) và ít phụ thuộc lẫn nhau
• Các service có thể được phát hiện một cách tự động. Các thành phần sử dụng service thường không cần biết vị trí chính xác và các chi tiết khác của serivce. Các đối tượng sử dụng service có thể khám phá metadata của service thông qua service metadata repository hoặc service registry. Khi có thay đổi đối với dữ liệu service có thể cập nhật dữ liệu của mình trong service registry
• Các service tổng hợp có thể được xây dựng từ việc tổng hợp các service khác (Ví dụ: chúng ta có 1 service tổng hợp báo cáo bán hàng theo sản phẩm, service này sẽ được tổng hợp từ hai service quản lý đơn hàng và quản lý sản phẩm)

Với mô hình SOA, mỗi chức năng nghiệp vụ được xây dựng như một service (chi tiết thô) (thường được triển khai dưới dạng webservice) với một số chức năng con. Các service này được triển khai bên trong một máy chủ ứng dụng. Khi nói đến việc sử dụng các chức năng nghiệp vụ, chúng ta thường cần phải tích hợp / gộp nhiều service như vậy (hoặc tạo ra các service tổng hợp) và các hệ thống khác. Enterprise Service Bus (ESB) được sử dụng để tích hợp các service, dữ liệu và các hệ thống với nhau. Các thành phần khác nhau trong hệ thống sử dụng các serivce tổng hợp được từ lớp ESB

Ví dụ: hãy quay lại trường hợp ứng dụng bán lẻ trực tuyến của chúng tôi. Hình trên minh họa việc triển khai ứng dụng bán lẻ trực tuyến sử dụng service SOA / web. Ở đây, chúng tôi đã xác định nhiều dịch vụ web phục vụ cho các chức năng về nghiệp vụ như sản phẩm, khách hàng, mua hàng, đơn đặt hàng, thanh toán, v.v. Ở lớp ESB, chúng tôi có thể tích hợp các chức năng nghiệp vụ đó và tạo ra các tính năng tổng hợp, cung cấp cho consumer. Hoặc lớp ESB có thể chỉ được sử dụng để cung cấp các chức năng như nó vốn có, hoặc liên quan đến bảo mật. Vì vậy, rõ ràng lớp ESB cũng chứa một phần đáng kể logic nghiệp vụ của toàn bộ ứng dụng. Cáctính năng như bảo mật, giám sát và phân tích cũng có thể được áp dụng ở lớp ESB. Lớp ESB là một thực thể nguyên khối, nơi tất cả các developer chia sẻ để phát triển / triển khai tích hợp service của họ

APIs

Việc thể hiện các chức năng nghiệp vụ dưới dạng các service hoặc API đã trở thành một yêu cầu quan trọng của kiến trúc phần mềm doanh nghiệp hiện đại. Tuy nhiên, các webservice / SOA không thực sự là giải pháp lý tưởng để đáp ứng các yêu cầu đó, do sự phức tạp của các công nghệ liên quan đến webservice như SOAP (được sử dụng làm định dạng thông báo cho giao tiếp giữa các service), WS-Security (để bảo mật gói tinh giữa các dịch vụ), WSDL (để xác định cấu trúc service), v.v. và việc thiếu các tính năng để xây dựng hệ sinh thái xung quanh các API

Do đó, hầu hết các nhóm phát triển đặt một lớp API Management / API Gateway mới lên trên các SOA hiện có. Lớp này được gọi là “mặt tiền” API và nó cho thấy một API đơn giản cho một chức năng nghiệp vụ nhất định và ẩn tất cả những phức tạp bên trong của lớp ESB /Webservice. Lớp API cũng được sử dụng để bảo mật, phân luồng, cache v.v.

Ví dụ, hình dưới đây giới thiệu API gateway trên đầu lớp ESB. Tất cả các tính năng nghiệp vụ được cung cấp từ ứng dụng bán lẻ trực tuyến của chúng tôi hiện đang được hiển thị dưới dạng các API.

Với nhu cầu ngày càng tăng về các tính năng nghiệp vụ phức tạp, kiến trúc nguyên khối không còn có thể đáp ứng cho việc phát triển ứng dụng phần mềm doanh nghiệp hiện đại. Bản chất tập trung của các ứng dụng nguyên khối dẫn đến việc thiếu khả năng mở rộng quy mô các ứng dụng một cách độc lập, sự phụ thuộc giữa các ứng dụng cản trở việc phát triển và triển khai ứng dụng độc lập, các vấn đề về độ tin cậy do tính chất tập trung và các ràng buộc trong việc sử dụng các công nghệ đa dạng để phát triển ứng dụng. Để khắc phục hầu hết những hạn chế này và để đáp ứng nhu cầu ứng dụng hiện đại, phức tạp và phi tập trung, một mô hình kiến trúc mới phải được hình thành.

Kiến trúc microservices đã nổi lên như một mô hình kiến trúc tốt hơn để khắc phục những nhược điểm của kiến trúc ESB / SOA cũng như kiến trúc ứng dụng nguyên khối thông thường

Microserivce là cái gì?

Nền tảng của kiến trúc microservices là về việc phát triển một ứng dụng đơn lẻ như một bộ các service nhỏ và độc lập đang chạy theo các quy trình của riêng chúng, được phát triển và triển khai độc lập

Như minh họa trong hình dưới, ứng dụng phần mềm bán lẻ trực tuyến có thể được chuyển đổi thành kiến trúc microservices bằng cách phá vỡ lớp ứng dụng nguyên khối thành các service định hướng theo các nghiệp vụ và độc lập. Ngoài ra, chúng tôi đã loại bỏ ESB trung tâm bằng cách chia nhỏ các chức năng của nó thành từng service, để các service đảm nhận logic cấu hình và giao tiếp giữa các service

Do đó, mỗi microservice ở lớp microservices cung cấp chức năng nghiệp vụ được xác định rõ (tốt nhất là với phạm vi nhỏ), được thiết kế, phát triển, triển khai và quản lý một cách độc lập.

Lớp API vẫn giữ nguyên khá nhiều, mặc dù có những thay đổi đối với lớp ESB và các lớp serivce mà nó giao tiếp. API Gateway và lớp quản lý thể hiện các chức năng nghiệp vụ dưới dạng các API; chúng ta có thể chọn tách riêng cổng thành các  cổng độc lập.

Và bây giờ bạn đã có hiểu biết cơ bản về kiến trúc microservices, chúng ta có thể đi sâu vào các đặc điểm chính của microservices.

Hướng quy mô nghiệp vụ

Một trong những khái niệm chính của kiến trúc microservices là service của bạn phải được thiết kế dựa trên nghiệp vụ, để một service nhất định sẽ phục vụ một nghiệp vụ cụ thể và có một bộ trách nhiệm được xác định rõ ràng. Một service nhất định chỉ nên tập trung vào làm một việc và làm tốt công việc đó. – “Nhất nghệ tinh, nhất thân vinh”

Điều quan trọng là phải hiểu rằng serivce thô (coarse-grained service) (chẳng hạn như webservice được phát triển trong ngữ cảnh SOA) hoặc service chi tiết (không liên quan đến nghiệp vụ) không phù hợp với kiến trúc microservices. Thay vào đó, service phải được “định cỡ” hoàn toàn dựa trên phạm vi và chức năng nghiệp vụ. Ngoài ra, hãy nhớ rằng việc tạo ra các service quá nhỏ (tức là được định hướng dựa trên các đối tượng chi tiết phù hợp với khả năng kinh doanh) cũng được coi là không phù hợp.

Trong tình huống ví dụ, chúng tôi đã có các dịch vụ chi tiết như Sản phẩm, Đơn đặt hàng, v.v. trong triển khai SOA / Webservice và khi chúng tôi chuyển sang microservice, chúng tôi đã xác định một tập hợp các service chi tiết hơn, nhưng định hướng nghiệp vụ, chẳng hạn như Chi tiết sản phẩm, Xử lý đơn hàng, Tìm kiếm sản phẩm, Mua sắm, Giỏ hàng, v.v.

Quy mô của service không bao giờ được xác định dựa trên số dòng code hoặc số developer làm việc trên service đó. Các khái niệm như Single Responsibility Principle (SRP), luật Conway, Twelve Factor App, Domain Driven Design (DDD), v.v., rất hữu ích trong việc xác định và thiết kế phạm vi và chức năng của một microservice. Chúng ta sẽ thảo luận về các khái niệm chính như vậy và các nguyên tắc cơ bản của việc thiết kế các microservice xung quanh các nghiệp vụ

Tính độc lập

“Tự chủ các serivce” là động lực quan trọng nhất đằng sau việc hiện thực hóa kiến trúc microservices. Microservices được phát triển, triển khai và mở rộng quy mô như các thực thể độc lập. Không giống như các webservice hoặc một kiến trúc ứng dụng nguyên khối, các service không chia sẻ cùng một runtime enviroment. Thay vào đó, chúng được triển khai dưới dạng runtime enviroment riêng biệt bằng cách tận dụng các công nghệ như container. Việc thích ứng thành công và ngày càng tăng của các container Docker, Kubernetes và Mesos dẫn đến sự thành công trong việc thực hiện vấn đề “tự chủ” của service và đóng góp vào sự thành công của kiến trúc microservices nói chung. Các bài viết sau sẽ đi sâu vào khía cạnh triển khai của microservices.

Các serivce “tự chủ” đảm bảo khả năng phục hồi của toàn bộ hệ thống vì chúng ta đã cách ly các lỗi thông qua việc cách ly service. Các service này được kết hợp với nhau liên kết với nhau qua inter-service. Giao tiếp giữa các dịch vụ có thể được xây dựng dựa trên nhiều kiểu tương tác và định dạng khác nhau và sẽ được trình bày chi tiết trong bài viết “Giao tiếp giữa các service”. Các service cung cấp các API của mình thông qua các service contracts và consumer có thể sử dụng các contract đó để gọi đến service. Các service như vậy cũng có thể được giao tiếp qua API và được quản lý thông qua API Gateway

Việc triển khai độc lập các service cung cấp khả năng để mở rộng các service (scale)  một cách độc lập. Khi mức tiêu thụ tài nguyên (RAM, CPUs,…) của các tính năng theo nghiệp vụ khác nhau, chúng ta có thể mở rộng quy mô các service cụ thể để nhận được nhiều lưu lượng truy cập hơn mà không cần mở rộng các service khác.

Hãy quan sát các đặc điểm của microservices này trong trường hợp sử dụng ứng dụng thương mại điện tử, được minh họa trong các hình trước. Các coarse-grained services, chẳng hạn như Sản phẩm, Đơn đặt hàng, v.v., chia sẻ cùng một runtime environment của máy chủ ứng dụng như trong phương pháp SOA /Webservice. Vì vậy, một lỗi (chẳng hạn như hết bộ nhớ hoặc CPU) ở một trong những service đó có thể gây lỗi cho toàn bộ hệ thống. Ngoài ra, trong nhiều trường hợp, các chức năng như tìm kiếm sản phẩm có thể được sử dụng rất thường xuyên so với các chức năng khác. Với cách tiếp cận nguyên khối, bạn không thể mở rộng quy mô (scale) các chức năng tìm kiếm sản phẩm vì nó chia sẻ cùng runtime environment của server với các service khác. Như được minh họa trong hình, việc tách biệt các service ban đầu thành các microservice giúp chúng có thể triển khai độc lập, tách các lỗi thành từng cấp service và cho phép bạn mở rộng quy mô (scale) một cách độc lập một service nhất định tùy thuộc vào cách nó được sử dụng.

Không có ESB

Kiến trúc microservices hỗ trợ việc loại bỏ Enterprise Service Bus (ESB). ESB từng là nơi chứa rất nhiều xử lý nghiệp vụ trong kiến trúc SOA /Webservice. Kiến trúc microservices giới thiệu một phong cách tích hợp service mới được gọi là smart endpoint và đường ống ngầm (Dumb pipes) thay vì sử dụng ESB. Như đã thảo luận trước đó trong chương này, hầu hết các logic nghiệp vụ được thực hiện ở lớp ESB thông qua tích hợp các service và hệ thống cơ bản. Với smart endpoint và đường ống câm (Dumb pipes), tất cả logic nghiệp vụ (bao gồm logic giao tiếp giữa các service) nằm ở mỗi cấp microservice và tất cả các service như vậy được kết nối với một hệ thống message (một đường ống) , không có bất kỳ logic nghiệp vụ nào.

Hầu hết những người sử dụng microservices đều nghĩ rằng chỉ cần chuyển đổi hệ thống thành kiến trúc microservices, họ có thể đơn giản loại bỏ tất cả sự phức tạp của kiến trúc ESB tập trung. Tuy nhiên, thực tế là với kiến trúc microservices, các khả năng tập trung của ESB được phân tán vào tất cả các microservices. Các chức năng mà ESB cung cấp hiện phải được triển khai ở cấp microservices

Vì vậy, điểm mấu chốt ở đây là sự phức tạp của ESB sẽ không biến mất. Thay vào đó, nó được phân phối giữa tất cả các microservices mà bạn phát triển. Các thành phần microservices (sử dụng kiểu đồng bộ hoặc không đồng bộ), giao tiếp với các service thông qua các giao thức khác nhau, áp dụng các pattern như circuit breakers, integrating with other applications, SaaS (Ví dụ: Salesforce), API, dữ liệu và proprietary systems và observability cần được triển khai như một phần của mciroservice mà bạn phát triển. Trên thực tế, sự phức tạp của việc tạo các giao tiếp giữa các service có thể khó khăn hơn trong một kiến trúc microservices (các service dễ bị lỗi hơn do giao tiếp giữa các service qua networks).

Hầu hết những doanh nghiệp áp dụng microservices đầu tiên như Netflix đã triển khai các tính năng này ngay từ đầu. Tuy nhiên, nếu muốn thay thế hoàn toàn ESB bằng kiến trúc microservices, chúng ta phải chọn các công nghệ cụ thể để xây dựng các tính năng của ESB đó ở cấp microservices thay vì triển khai lại chúng từ đầu

Khả năng chịu lỗi của hệ thống

Như đã thảo luận trong phần trước, các microservice dễ bị lỗi hơn do sự gia tăng của các service và giao tiếp qua mạng giữa các service. Một ứng dụng microservice nhất định là một tập hợp các service và do đó lỗi của một hoặc nhiều service đó sẽ không làm cho toàn bộ ứng dụng bị phá hủy. Do đó, phải xử lý một cách khéo léo một lỗi nhất định của một microservice để nó có tác động tối thiểu đến các logic nghiệp vụ của ứng dụng. Thiết kế microservices theo kiểu có thể chịu được lỗi đòi hỏi sự thích ứng của các công nghệ cần thiết từ giai đoạn thiết kế, phát triển và triển khai

Ví dụ: trong ví dụ về hệ thống bán lẻ, giả sử product service rất quan trọng đối với chức năng của ứng dụng thương mại điện tử. Do đó, chúng ta cần áp dụng tất cả các khả năng liên quan đến khả năng phục hồi, chẳng hạn như circuit breakers, disaster recovery, load balancing, fail-over, và dynamic scaling dựa trên các mẫu lưu lượng sẽ được thảo luận chi tiết hơn ở bài sau

Điều thực sự quan trọng là giả định tất cả các lỗi có thể xảy ra như một phần của quá trình phát triển và kiểm thử (test) service, bằng cách sử dụng các công cụ như Netflix’s Chaos Monkey. Việc triển khai service nhất định cũng phải chịu trách nhiệm về tất cả các hoạt động liên quan đến khả năng phục hồi; những thao thác này được xem như một phần của quy trình CICD (continuous integration, continuous delivery)

Khía cạnh khác của khả năng chịu lỗi là khả năng quan sát hành vi của các service trong môi trường production. Việc phát hiện hoặc dự đoán các lỗi trong một service và khôi phục các service đó là khá quan trọng. Ví dụ: giả sử rằng bạn đã bật tính năng monitor, tracing, write log, v.v. cho tất cả các service của mình trong ví dụ về ứng dụng bán lẻ trực tuyến. Sau đó, bạn quan sát thấy độ trễ đáng kể và TPS thấp (Transactions per second) trong dịch vụ “Tìm kiếm sản phẩm.” Đây là dấu hiệu cho thấy service đó có thể ngừng hoạt động trong tương lai. Nếu các service được giám sát, bạn sẽ có thể phân tích lý do gây ra các triệu chứng hiện tại. Do đó, ngay cả khi bạn đã kiểm thử trong giai đoạn phát triển, điều quan trọng là phải có một cơ sở hạ tầng hỗ trợ giám sát vững chắc để tất cả các service của bạn đạt được khả năng chịu lỗi cao.

Quản lý dữ liệu phi tập trung

Trong một kiến trúc nguyên khối, ứng dụng lưu trữ dữ liệu trong các cơ sở dữ liệu duy nhất và tập trung để triển khai các chức năng / khả năng khác nhau của ứng dụng. Trong kiến trúc microservices, các chức năng được phân tán trên nhiều microservices. Nếu chúng ta sử dụng cùng một cơ sở dữ liệu tập trung, các service sẽ không còn độc lập với nhau (ví dụ: nếu thiết kế cơ sở dữ liệu bị thay đổi bởi một service, điều đó sẽ phá vỡ một số service khác). Do đó, mỗi microservice phải có cơ sở dữ liệu và thiết kế cơ sở dữ liệu riêng

Mỗi microservice có thể có một cơ sở dữ liệu riêng để lưu giữ dữ liệu yêu cầu triển khai chức năng nghiệp vụ do nó cung cấp. Một service nhất định chỉ có thể truy cập cơ sở dữ liệu của liên quan đến các tính năng nghiệp vụ nó quản lý 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 về mặt nghiệp vụ, 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 tình huống như vậy, cơ sở dữ liệu của các service khác chỉ nên được cập nhật thông qua API tương ứng (chúng không được phép truy cập trực tiếp vào cơ sở dữ liệu)

Việc quản lý dữ liệu phi tập trung cung cấp cho bạn các service được tách biệt hoàn toàn và sự tự do lựa chọn các kỹ thuật quản lý dữ liệu khác nhau (SQL hoặc NoSQL, v.v, các hệ thống quản lý cơ sở dữ liệu khác nhau cho từng service). Hãy xem xét chi tiết các kỹ thuật quản lý dữ liệu của kiến trúc microservices trong bài cụ thể liên quan

Quản lý service

Quản trị service là một trong những động lực chính thúc đẩy sự thành công trong hoạt động của SOA; nó cung cấp sự hợp tác và phối hợp giữa các đối tượng khác nhau trong một tổ chức (nhóm phát triển, người dùng, v.v.). Mặc dù nó xác định một tập hợp các khái niệm lý thuyết toàn diện trong quản trị SOA, nhưng chỉ một số ít các khái niệm đang được sử dụng tích cực trong thực tế. Khi chúng ta chuyển sang kiến trúc microservices, hầu hết các khái niệm quản trị hữu ích đều bị loại bỏ và quản trị trong microservices được hiểu là một quy trình phi tập trung, cho phép mỗi nhóm / tổ chức quản lý tên miền riêng của mình theo ý muốn. Quản trị phi tập trung có thể áp dụng cho quá trình phát triển, triển khai và vận hành, nhưng còn nhiều điều hơn thế nữa. Do đó, ở đây không sử dụng thuật ngữ quản trị phi tập trung.

Chúng ta có thể xác định hai khía cạnh chính của quản trị: quản trị thời gian thiết kế (design time) của service (lựa chọn công nghệ, giao thức, v.v.) và quản lý runtime (định nghĩa service, service registry và discovery, phiên bản service, service runtime dependencies, service ownership - trách nhiệm của team đối với service và consumers,…).

Quản trị thời gian thiết kế (design-time) trong microservices hầu hết là một quy trình phi tập trung, trong đó mỗi service owner (người quản lý và chịu trách nhiệm về service) được quyền tự do thiết kế, phát triển và vận hành các service của họ. Sau đó, họ có thể sử dụng công cụ, lựa chọn công nghệ phù hợp cho công việc, cho đội nhóm họ, thay vì tiêu chuẩn hóa trên một công nghệ duy nhất. Tuy nhiên, nên xác định một số tiêu chuẩn chung có thể áp dụng trong toàn tổ chức (ví dụ: không phân biệt ngôn ngữ lập trình, tất cả code phải trải qua quá trình xem xét (review) và tự động merge vào nhánh chính)

Khía cạnh quản trị runtime của microservices được triển khai ở nhiều cấp độ khác nhau và chúng ta thường không gọi nó là quản trị runtime trong ngữ cảnh microservices (service registry và service discovery là một khái niệm phổ biến cực kỳ hữu ích trong kiến trúc microservices). Vì vậy, thay vì tìm hiểu về những khái niệm này như một tập hợp các khái niệm rời rạc, sẽ dễ hiểu chúng hơn nếu chúng ta nhìn vào quan điểm quản trị runtime.

Quản trị runtime là cực kỳ quan trọng trong kiến trúc microservices (nó thậm chí còn quan trọng hơn quản trị runtime SOA), đơn giản vì số lượng microservices mà chúng ta phải xử lý. Việc thực hiện quản trị runtime thường được thực hiện như một thành phần tập trung. Ví dụ: giả sử rằng chúng ta cần tìm kiếm các endpoint và metadata trong bài toán về hệ thống bán lẻ trực tuyến. Sau đó, tất cả các service phải gọi một service đăng ký tập trung (service này có thể có khả năng mở rộng quy mô riêng, nhưng là một thành phần tập trung hợp lý). Tương tự, nếu chúng ta muốn áp dụng các tiêu chuẩn QoS (quality of service) chẳng hạn như bảo mật, với phương pháp config tập trung, chúng ta cần một nơi cung cấp API / gateway. Trên thực tế, một số khía cạnh quản trị runtime cũng được triển khai ở lớp API gateway

Khả năng quan sát

Khả năng quan sát dịch vụ có thể được coi là sự kết hợp của việc giám sát, ghi log phân tán, tracing phân tán và giám sát hành vi của các service. Do đó, khả năng quan sát cũng có thể được coi là một phần của quản trị runtime. Với sự gia tăng của các microservice, khả năng quan sát các hành vi ở môi trường của một service là hoàn toàn quan trọng. Các thành phần quan sát thường là một thành phần tập trung trong việc triển khai microservices và các service đẩy dữ liệu vào các thành phần đó. Khả năng quan sát rất hữu ích để xác định và gỡ lỗi các vấn đề tiềm ẩn, trong khi các service đang được phát triển và cũng có thể được sử dụng cho các mục đích chức năng kinh doanh

Microservice: Lợi ích và thách thức

Như với bất kỳ kiến trúc hoặc công nghệ nào, đối với kiến trúc microservices cũng có những lợi ích và thách thức.  Hãy bắt đầu với những lợi ích của microservices

Một trong những lý do chính cho sự phổ biến của kiến trúc microservices là những lợi ích mà nó mang lại so với các mẫu kiến trúc phần mềm thông thường. 

Áp dụng Agile và việc phát triển nhanh các chức năng nghiệp vụ

Kiến trúc microservices ủng hộ việc phát triển service độc lập, giúp cho việc phát triển linh hoạt và nhanh chóng các chức năng nghiệp vụ. Trong một kiến trúc thông thường, việc chuyển đổi một quy trình nghiệp vụ sang một chức năng tương ứng trên phần mềm cần nhiều chu kỳ, chủ yếu do kích thước của hệ thống, code base và các yếu tố phụ thuộc. Với việc phát triển các service độc lập, bạn chỉ cần tập trung vào interface và chức năng của service (không phải chức năng của toàn bộ hệ thống, phức tạp hơn nhiều), vì tất cả các service khác chỉ giao tiếp thông qua mạng.

Khả năng thay thế

Do tính chất tự trị và độc lập của nó, microservices cũng có thể thay thế được. Vì chúng ta đang xây dựng các service như một thực thể độc lập, giao tiếp thông qua các API được xác định, chúng ta có thể dễ dàng thay thế chức năng đó bằng một cách triển khai khác tốt hơn. Tập trung vào một chức năng cụ thể, có phạm vi và kích thước hạn chế và triển khai nó trong runtime độc lập, tất cả đều giúp việc xây dựng một service có thể thay thế dễ dàng hơn nhiều

Sự cô lập và khả năng xác định lỗi

Khả năng thay thế cũng giúp chúng ta đạt được sự cô lập và dự đoán hoặc xác định lỗi. Như đã thảo luận, một ứng dụng dựa trên microservices không thể bị “shutdown” như một ứng dụng nguyên khối thông thường do lỗi của bất kỳ thành phần hoặc service nhất định nào. Có các tính năng theo dõi, giám sát (log,…) cũng giúp chúng ta xác định hoặc dự đoán các lỗi tiềm ẩn

Triển khai linh hoạt và dễ mở rộng

Dễ dàng triển khai và mở rộng quy mô cũng có thể là giá trị quan trọng nhất của microservices. Với cơ sở hạ tầng container dựa trên nền tảng cloud, khả năng dễ dàng triển khai một service và mở rộng quy mô một cách linh hoạt đang trở nên tầm thường. Vì đang xây dựng các khả năng như các service độc lập microservice có thể dễ dàng tận dụng tất cả các công nghệ cloud và container như vậy để tạo điều kiện cho việc triển khai linh hoạt và khả năng mở rộng.

Phù hợp với cơ cấu tổ chức

Vì microservices được định hướng theo nghiệp vụ nên chúng cũng có thể phù hợp với cấu trúc tổ chức / nhóm. Thường thì một tổ chức nhất định được cấu trúc theo cách mà nó mang lại hiệu quả kinh doanh. Do đó, việc sở hữu mỗi dịch vụ có thể dễ dàng được trao cho các làm việc với nghiệp vụ liên quan. Do đó, với việc một microservice tập trung vào chức năng nghiệp vụ cụ thể, bạn có thể chọn một nhóm tương đối nhỏ để sở hữu microservice đó. Điều này có tác động tích cực đến nhóm phát triển, vì phạm vi của một service nhất định rất đơn giản và được xác định rõ ràng. Bằng cách đó, nhóm hoàn toàn có thể sở hữu toàn bộ vòng đời của service

Hầu hết các thách thức của kiến trúc microservices chủ yếu là do sự gia tăng của các service mà bạn cần thực hiện cũng như quản lý

Giao tiếp giữa các service

Sự phức tạp của giao tiếp giữa các service có thể khó khăn hơn so với việc triển khai các service thực tế. Như đã thảo luận trước đó, khái niệm smart endpoint và dumb pipe buộc chúng ta phải có logic giao tiếp giữa các service như một phần của microservice của chúng ta. Các nhà phát triển service phải dành một lượng thời gian đáng kể vào việc kết hợp các microservices về hệ thống dumb pipe để tạo ra một chức năng nghiệp vụ tổng hợp

Quản trị service

Việc các service giao tiếp qua các network cũng làm phức tạp khía cạnh quản trị và khả năng giám sát của các service. Nếu bạn không có các công cụ theo dõi và khả năng giám sát thích hợp, sẽ là một cơn ác mộng để xác định sự phụ thuộc của service và phát hiện các lỗi. Ví dụ: quản lý vòng đời service, kiểm tra, giám sát, QoS và nhiều khả năng quản trị service khác sẽ trở nên phức tạp hơn với kiến trúc microservices.

Phụ thuộc nhiều vào phương thức triển khai

Sự thành công của việc triển khai và mở rộng các microservices phụ thuộc nhiều vào việc áp dụng container và hệ thống orchestration (các công cụ, dịch vụ dùng để điều phối và quản lý nhiều container sao cho chúng làm việc một cách hiệu quả nhất). Nếu bạn chưa có cơ sở hạ tầng như vậy, bạn sẽ cần đầu tư thời gian và công sức cho nó (và thậm chí đừng nghĩ đến việc có một kiến trúc microservices thành công mà không áp dụng container). Cuối cùng, một kiến trúc microservices thành công cũng phụ thuộc vào các nhóm và con người. Service owner, suy nghĩ về lightweight service, loại bỏ điểm trung tâm để tích hợp các service, v.v., đòi hỏi phải thay đổi văn hóa kỹ thuật cấp tổ chức

Sự phức tạp của dữ liệu phân tán và quản lý transaction

Vì kiến trúc microservices thúc đẩy cá nhân hóa về mặt cơ sở dữ liệu cho một service nhất định, nên việc quản lý dữ liệu phân tán sẽ khá khó khăn. Điều tương tự cũng áp dụng cho các giao dịch phân tán. Việc thực hiện các ranh giới giao dịch trải dài trên nhiều dịch vụ nhỏ sẽ khá khó khăn.

Sử dụng microservices khi nào và lúc nào

Bài viết đã thảo luận về cách kiến trúc microservices đã phát triển từ kiến trúc doanh nghiệp tập trung thông thường, đề cập đến các đặc điểm chính của nó và thảo luận về những ưu và nhược điểm của việc sử dụng nó. Tuy nhiên, cũng cần có một bộ nguyên tắc vững chắc về thời điểm sử dụng kiến trúc microservices và khi nào thì nên tránh nó.

• Kiến trúc microservices là lý tưởng khi doanh nghiệp hiện tại của bạn yêu cầu mô-đun hóa
• Nếu vấn đề nghiệp vụ mà bạn đang cố gắng giải quyết với ứng dụng phần mềm của mình khá đơn giản, bạn có thể không cần microservices (chỉ có một ứng dụng web nguyên khối đơn giản và cơ sở dữ liệu thường là đủ)
• Ứng dụng phần mềm của bạn phải triển khai dựa trên container
• Nếu hệ thống của bạn quá phức tạp để có thể tách biệt thành các microservices, bạn nên xác định các khu vực mà bạn có thể áp dụng microservices với tác động tối thiểu. Sau đó, bắt đầu triển khai một trường hợp sử dụng nhỏ trên microservices và xây dựng các thành phần hệ sinh thái cần thiết xung quanh đó.
• Hiểu được nghiệp vụ là điều khá quan trọng để thiết kế các microservice
• Đối với từng đặc điểm về hệ thống microservice cụ thể (chẳng hạn như quản lý dữ liệu, giao tiếp giữa các service, bảo mật, v.v.), chúng ta sẽ thảo luận chi tiết về các phương pháp hay nhất và cách chống trong các chương sắp tới.

Tóm tắt

Chương này cung cấp cho bạn cái nhìn tổng quan về trạng thái hiện tại của kiến trúc phần mềm doanh nghiệp và cách các microservices tác động đến nó. Trong bài này, đã thảo luận về cách kiến trúc doanh nghiệp đã phát triển từ các ứng dụng nguyên khối sang microservice. Trong bài cũng đã thảo luận về vai trò của ESB và API gateway thay đổi như thế nào khi chuyển sang microservices. Chúng ta cũng đã thảo luận về các đặc điểm chính của kiến trúc microservices và những ưu và nhược điểm của nó, đây sẽ là nền tảng cho toàn bộ series