Vi dịch vụ là một cách chia một ứng dụng lớn thành các mô-đun được liên kết lỏng lẻo để giao tiếp với nhau thông qua một API đơn giản.
Gần đây chỉ có những người ngu ngốc mới không nói về microservice. Điều này ngày càng trở nên phổ biến. Phong cách kiến trúc mô-đun có vẻ đặc biệt phù hợp với môi trường dựa trên đám mây và ngày càng phổ biến. Trước khi đi vào chi tiết, chúng ta hãy nhìn toàn cảnh mọi thứ . Do đó: Microservice là một cách chia một dự án lớn thành các mô-đun nhỏ, độc lập và được liên kết lỏng lẻo. Các mô-đun độc lập chịu trách nhiệm thực hiện các nhiệm vụ riêng biệt và được xác định rõ ràng, đồng thời giao tiếp với nhau thông qua một API đơn giản và dễ tiếp cận. Nói cách khác, microservice đơn giản là một phong cách kiến trúc khác để thiết kế các ứng dụng web phức tạp, chủ yếu là. Nhưng có gì tệ về các giải pháp kiến trúc hiện tại như SOA (Kiến trúc hướng dịch vụ)? Hầu hết các giải pháp doanh nghiệp hiện đại được viết bằng SOA dường như hoạt động khá tốt. Đây có thể là thời điểm tuyệt vời để nói về một số thách thức mà ngành đang phải đối mặt ngày nay... Hãy bắt đầu bằng một ví dụ đơn giản. Giả sử tôi cần chạy một ứng dụng cổ điển được viết bằng Java. Đầu tiên tôi sẽ phát triển Giao diện người dùng, sau đó là lớp logic nghiệp vụ, với một số thành phần sẽ tương tác với giao diện người dùng và cuối cùng là lớp cơ sở dữ liệu, có thể truy cập được vào cơ sở dữ liệu liên tục. Bây giờ tùy theo nhu cầu chạy ứng dụng, tôi sẽ tạo một WAR/EAR/JAR và mount nó lên một máy chủ (chẳng hạn như JBoss, Tomcat hoặc WebLogic). Vì việc này được thực hiện tất cả trong một nên tôi nhận được một ứng dụng nguyên khối, nghĩa là tất cả các thành phần đều ở một nơi... Ví dụ trong hình:
Rất có thể, bạn đã quen với cách tiếp cận này và đã sử dụng nó, nhưng ý tưởng là sử dụng ví dụ này để chỉ ra những thách thức mà nhà phát triển sẽ phải đối mặt khi sử dụng giải pháp kiến trúc này. Ứng dụng nguyên khối: thách thức thách thức
Khi ứng dụng phát triển, số lượng mã được viết cũng tăng lên, điều này có thể làm quá tải môi trường phát triển mỗi khi bạn cần mở nó. Điều này chắc chắn làm giảm hiệu quả của nhà phát triển.
Vì mọi thứ đều phải được gắn vào một nơi nên việc chuyển sang ngôn ngữ lập trình khác hoặc chuyển sang công nghệ khác là một vấn đề lớn. Ví dụ: bạn đã viết một ứng dụng bằng Java và sau một thời gian, Kotlin xuất hiện và bạn háo hức viết lại nó vì nó được quảng cáo là mát hơn, tốt hơn, nhanh hơn. Với một ứng dụng nguyên khối, ngay cả việc nghĩ đến việc tái cấu trúc cũng sẽ gây ra đau đớn thực sự, chưa kể đến chính quá trình đó. Hiện tại có rất nhiều ứng dụng được tạo ra theo cách này và số lượng dòng mã đơn giản là không thể tin được.
Nếu bất kỳ thành phần nào ngừng hoạt động vì bất kỳ lý do gì , toàn bộ ứng dụng cũng sẽ bị lỗi. Chỉ cần tưởng tượng rằng có một ứng dụng web có các mô-đun như ủy quyền, thanh toán, lịch sử, v.v. Và vì lý do nào đó mà một trong số chúng bị hỏng. Đây đơn giản là một cú sốc đối với doanh nghiệp và do đó đối với các nhà phát triển.
Việc mở rộng quy mô một ứng dụng nguyên khối chỉ có thể đạt được bằng cách nâng cao một ứng dụng khác cùng loại. Nhưng điều gì sẽ xảy ra nếu bạn chỉ cần mở rộng quy mô một thành phần chứ không phải toàn bộ ứng dụng. Bao nhiêu nguồn lực sẽ bị lãng phí?...
Điều này có thể ảnh hưởng lớn đến quá trình phát triển và quá trình cài đặt ứng dụng. Ứng dụng càng lớn thì điều quan trọng là các nhà phát triển có thể chia ứng dụng thành các phần hoạt động nhỏ hơn. Bởi vì tất cả các mô-đun trong một ứng dụng nguyên khối đều được kết nối với nhau nên các nhà phát triển không thể làm việc/gắn kết các mô-đun này một cách độc lập với nhau. Vì các nhà phát triển phụ thuộc vào nhau nên thời gian phát triển sẽ tăng lên.
Đồng thời, chúng tôi sẵn sàng xem xét và hiểu ý nghĩa của microservice, cụ thể là cách chúng có thể được sử dụng để khôi phục tính linh hoạt đã bị mất theo kiểu SOA. God Microservices sẽ giải cứu Một trong những đặc điểm quan trọng nhất trong bất kỳ giải pháp kiến trúc nào là khả năng mở rộng. Khi tôi học microservice lần đầu tiên, tôi thấy mọi thứ rất giống với những câu trích dẫn trong cuốn sách “Nghệ thuật mở rộng quy mô”. Đây là một khởi đầu tuyệt vời và là nơi để thảo luận. Cuốn sách này định nghĩa cái gọi là mô hình "Khối khả năng mở rộng", mô tả hệ thống có khả năng mở rộng ba chiều:
Như bạn có thể thấy, trục X mô tả "tỷ lệ theo chiều ngang" (mà chúng ta đã thấy cũng có sẵn cho các kiến trúc nguyên khối), trục Y biểu thị tỷ lệ theo nghĩa tách biệt các thành phần dịch vụ khác nhau . Ý tưởng về trục Z được hiểu khi dữ liệu được phân chia và ứng dụng gửi yêu cầu đến chính xác nơi chứa dữ liệu. Đó là, tất cả chúng không ở cùng một nơi. Ý tưởng về trục Y là ý tưởng mà chúng ta sẽ tập trung chi tiết hơn. Trục này thể hiện sự phân rã chức năng . Trong chiến lược này, các chức năng khác nhau có thể được coi là các dịch vụ độc lập. Do đó, bằng cách chỉ cài đặt toàn bộ ứng dụng khi mọi thứ đã hoàn tất, các nhà phát triển có thể gắn kết các dịch vụ riêng lẻ độc lập với nhau và không phải đợi người khác hoàn thành công việc trên các mô-đun của họ. Điều này sẽ không chỉ cải thiện thời gian phát triển mà còn mang lại sự linh hoạt để thay đổi và kết nối lại mà không phải lo lắng về các thành phần còn lại của ứng dụng. Hãy so sánh sơ đồ này với sơ đồ nguyên khối trước đó:
Microservices: Lợi ích Lợi ích của microservices dường như khá đủ để thuyết phục các nhà phát triển doanh nghiệp như Amazon, Netflix, Ebay bắt đầu sử dụng phương pháp này. Không giống như các ứng dụng kiến trúc nguyên khối, microservice:
Cải thiện khả năng cách ly lỗi thành phần: Các ứng dụng lớn có thể tiếp tục chạy hiệu quả ngay cả khi một mô-đun bị lỗi.
Loại bỏ cam kết của ứng dụng đối với một nhóm công nghệ: nếu bạn muốn thử một nhóm công nghệ mới trên một số dịch vụ, hãy tiếp tục. Các phần phụ thuộc sẽ nhẹ hơn nhiều so với một phần phụ thuộc nguyên khối và việc khôi phục mọi thứ cũng sẽ dễ dàng hơn nhiều. Càng ít mã trong một ứng dụng thì càng dễ làm việc.
Giúp nhân viên mới hiểu chức năng của dịch vụ dễ dàng hơn nhiều.
Vi dịch vụ: tính năng gắn kết và ảo hóa Bây giờ chúng ta đã hiểu vi dịch vụ là gì. Và ưu điểm lớn nhất là nó được gắn bởi nhiều hơn một kho lưu trữ WAR/EAR/JAR. Nhưng nó được cài đặt như thế nào? Cách tốt nhất để gắn microservice bên trong container. Vùng chứa là một hệ điều hành ảo được cấu hình đầy đủ với môi trường cần thiết được định cấu hình, giúp cách ly quyền truy cập vào tài nguyên của hệ thống phần cứng nơi vùng chứa được cài đặt. Giải pháp nổi tiếng nhất trên thị trường tất nhiên là Docker . Các máy ảo từ IaaS (cơ sở hạ tầng dưới dạng dịch vụ) như AWS cũng có thể hoạt động tốt để gắn các vi dịch vụ, nhưng các vi dịch vụ tương đối nhẹ có thể không sử dụng tất cả tài nguyên có trong máy ảo, điều này có thể làm giảm lợi nhuận khi sử dụng. Bạn cũng có thể gắn kết các vi dịch vụ của mình bằng gói OSGI (Sáng kiến cổng dịch vụ mở). Trong trường hợp này, tất cả vi dịch vụ sẽ chạy trong một JVM duy nhất, nhưng điều này liên quan đến vấn đề cân bằng giữa khả năng kiểm soát và cách ly. Dịch vụ vi mô: Nhược điểm Chỉ vì “cái này thật tuyệt” và “chúng tôi chưa từng thấy điều này trước đây” không có nghĩa là không có nhược điểm. Dưới đây là danh sách các vấn đề có thể gặp phải mà kiến trúc microservice mang lại:
Phát triển hệ thống phân tán có thể khó khăn. Ý tôi là bây giờ tất cả các thành phần đều là các dịch vụ độc lập - bạn cần xử lý rất cẩn thận các yêu cầu chuyển giữa các mô-đun. Có thể xảy ra trường hợp một mô-đun không phản hồi, buộc bạn phải viết mã bổ sung để tránh làm hỏng hệ thống. Điều này có thể khó khăn hơn nếu các cuộc gọi từ xa nhạy cảm với độ trễ .
Nhiều cơ sở dữ liệu và quản lý giao dịch có thể là một vấn đề thực sự.
Việc kiểm thử các ứng dụng microservice có thể rất phức tạp. Sử dụng một ứng dụng nguyên khối, chúng ta chỉ cần chạy kho lưu trữ WAR/EAR/JAR trên máy chủ và đảm bảo rằng nó được kết nối với cơ sở dữ liệu. Và trong microservice, mỗi dịch vụ riêng lẻ phải được khởi động trước khi bắt đầu thử nghiệm.
Việc gắn kết các ứng dụng có thể khó khăn. Chúng có thể yêu cầu sự phối hợp xung quanh nhiều dịch vụ có thể không dễ lắp đặt như vùng chứa WAR.
.... Tất nhiên, với các công cụ và cách tiếp cận phù hợp, những nhược điểm này có thể tránh được. Nhưng bản thân họ cần được hỗ trợ và không giải quyết được triệt để mọi vấn đề. Bài viết được dịch từ trang web CloudAcademy . Dịch miên phi. Mọi người đều có quyền bày tỏ mọi suy nghĩ của mình trong phần bình luận. Họ chắc chắn sẽ được đọc. Bài viết gốc Tài khoản Github của tôi
GO TO FULL VERSION