Hướng dẫn microservice

Kiến trúc microservice là một trong những xu hướng kiến ​​trúc phần mềm được thảo luận nhiều nhất hiện nay. Nó đã thay đổi cách các ứng dụng doanh nghiệp được xây dựng mãi mãi. Thay vì cách tiếp cận nguyên khối phức tạp chậm chạp trước đây, các nhà phát triển và công ty ở khắp mọi nơi đang chuyển sang kiến ​​trúc microservices để đơn giản hóa và mở rộng cấu trúc của họ. Ngay cả các công ty như Amazon, Netflix, Spotify và Uber cũng đã thực hiện chuyển đổi.

Cho dù bạn muốn bắt đầu với microservices hay chỉ tò mò về cuộc tranh luận xung quanh nó, bạn đang ở đúng nơi. Hôm nay, tôi sẽ hướng dẫn bạn mọi thứ bạn cần biết về microservices, từ các ví dụ trong thế giới thực đến các mẫu kiến ​​trúc và hơn thế nữa. Chúng tôi sẽ đề cập đến những điều sau:

• Kiến trúc microservices là gì?
• Lợi ích và hạn chế
• Microservices và Docker
• Ngăn xếp công nghệ và mô hình kiến ​​trúc
• Hướng dẫn tài nguyên

Kiến trúc Microservices là gì?

Không có định nghĩa chung về thuật ngữ microservices. Định nghĩa đơn giản nhất về microservices, còn được gọi là kiến ​​trúc microservice, là một phong cách kiến ​​trúc cấu trúc một ứng dụng bằng cách sử dụng các dịch vụ được kết hợp lỏng lẻo. Các tập hợp hoặc mô-đun này có thể được phát triển, triển khai và duy trì một cách độc lập.

Chúng hoạt động nhanh hơn và đáng tin cậy hơn nhiều so với các ứng dụng nguyên khối, phức tạp truyền thống. Sử dụng kiến ​​trúc microservice, một tổ chức ở bất kỳ quy mô nào đều có thể phát triển các công nghệ, phù hợp với khả năng của họ.

Có rất nhiều lợi ích hữu hình khi sử dụng microservices mà chúng ta sẽ thảo luận ở phần sau, nhưng vẫn còn một số tranh cãi về việc các công ty có nên chuyển từ kiến ​​trúc nguyên khối sang microservices hay không. Hãy xem xét sự khác biệt giữa hai để giúp chúng ta hiểu cuộc tranh luận.

Nguyên khối so với Microservices

Kiến trúc nguyên khối là cách xây dựng và triển khai ứng dụng truyền thống. Cấu trúc này dựa trên khái niệm về một đơn vị duy nhất, không thể phân chia, bao gồm phía máy chủ, phía máy khách và cơ sở dữ liệu. Tất cả các khía cạnh được thống nhất và được quản lý như một đơn vị duy nhất và cơ sở mã. Điều này có nghĩa là mọi bản cập nhật phải được thực hiện cho cùng một cơ sở mã, vì vậy toàn bộ ngăn xếp phải được thay đổi. Khi các ứng dụng nguyên khối mở rộng quy mô, chúng có thể trở nên khá phức tạp, vì vậy quá trình phát triển tổng thể nói chung là lâu hơn.

Mặt khác, một kiến ​​trúc microservices chia đơn vị đó thành nhiều đơn vị độc lập hoạt động như các dịch vụ riêng biệt. Điều này có nghĩa là mọi dịch vụ đều có logic và cơ sở mã riêng của nó. Chúng giao tiếp với nhau thông qua các API [Giao diện lập trình ứng dụng].

Vậy, bạn nên chọn kiến ​​trúc nào? Hãy phá vỡ nó.

Chọn một kiến ​​trúc nguyên khối

• Nếu công ty của bạn là một đội nhỏ. Bằng cách này, bạn không phải đối mặt với sự phức tạp của việc triển khai một kiến ​​trúc microservice.
• Nếu bạn muốn khởi chạy nhanh hơn. Kiến trúc nguyên khối cần ít thời gian hơn để khởi chạy. Hệ thống này sẽ cần thêm thời gian sau đó để cập nhật hệ thống của bạn, nhưng việc khởi chạy ban đầu sẽ nhanh hơn.

• Nếu bạn muốn phát triển một ứng dụng có khả năng mở rộng hơn. Mở rộng quy mô kiến ​​trúc microservices dễ dàng hơn nhiều. Các khả năng và mô-đun mới có thể được thêm vào dễ dàng và nhanh chóng.
• Nếu công ty của bạn lớn hơn hoặc có kế hoạch phát triển. Sử dụng microservices là một điều tuyệt vời cho một công ty có kế hoạch phát triển, vì kiến ​​trúc microservices có khả năng mở rộng hơn nhiều và dễ tùy chỉnh hơn.

Có một số lý do khiến kiến ​​trúc microservices có thể là lựa chọn tốt hơn cho công ty của bạn. Hãy thảo luận về những lợi ích đáng chú ý nhất và sau đó xem xét một số hạn chế.

Những lợi ích

• Cải thiện khả năng mở rộng và năng suất. Các đội lớn thường phải làm việc cùng nhau trong các dự án phức tạp. Với microservices, các dự án có thể được chia thành các đơn vị nhỏ hơn, độc lập. Điều này có nghĩa là các nhóm có thể hành động độc lập liên quan đến logic miền, điều này giảm thiểu sự phối hợp và nỗ lực. Trên hết, các nhóm chịu trách nhiệm cho mỗi microservice có thể đưa ra quyết định công nghệ của riêng họ tùy thuộc vào nhu cầu của họ.

• Tích hợp tốt với các hệ thống kế thừa. Hệ thống nguyên khối rất khó bảo trì. Nhiều hệ thống cũ có cấu trúc kém, được kiểm tra kém hoặc phụ thuộc vào các công nghệ lỗi thời. May mắn thay, microservices có thể hoạt động cùng với các hệ thống kế thừa để cải thiện mã và thay thế các phần cũ của hệ thống. Tích hợp rất dễ dàng và có thể giải quyết nhiều vấn đề khiến các hệ thống nguyên khối trở thành quá khứ.
• Phát triển bền vững. Các kiến ​​trúc microservice tạo ra các hệ thống có thể bảo trì về lâu dài vì các bộ phận khác nhau có thể thay thế được. Điều này có nghĩa là một microservice có thể dễ dàng được viết lại mà không ảnh hưởng đến toàn bộ hệ thống. Miễn là sự phụ thuộc giữa các microservices được quản lý phù hợp, bạn có thể dễ dàng thực hiện các thay đổi để tối ưu hóa nhu cầu và hiệu suất của nhóm.
• Chức năng chéo. Microservices là tốt nhất cho các nhóm phân tán. Nếu bạn có các nhóm trên khắp thế giới hoặc các bộ phận khác nhau, microservices cấp cho các quyền tự do và tính linh hoạt cần thiết để làm việc tự chủ. Các quyết định kỹ thuật có thể được đưa ra nhanh chóng để tích hợp với các dịch vụ khác trong nháy mắt. Chức năng chéo chưa bao giờ dễ dàng hơn thế.

• Việc triển khai đòi hỏi nhiều nỗ lực hơn. Hoạt động của một hệ thống microservice thường đòi hỏi nhiều nỗ lực hơn, vì có nhiều đơn vị có thể triển khai hơn phải được triển khai và giám sát. Các thay đổi đối với giao diện phải được thực hiện để vẫn có thể triển khai độc lập các dịch vụ vi mô riêng lẻ.
• Kiểm tra phải độc lập. Vì tất cả các dịch vụ vi mô phải được thử nghiệm cùng nhau, một dịch vụ vi mô có thể chặn giai đoạn thử nghiệm và ngăn việc triển khai các dịch vụ vi mô khác. Có nhiều giao diện hơn để kiểm tra và kiểm tra phải độc lập cho cả hai bên của giao diện.
• Khó thay đổi nhiều microservices. Những thay đổi ảnh hưởng đến nhiều dịch vụ nhỏ có thể khó thực hiện hơn. Trong một hệ thống microservice, các thay đổi yêu cầu một số triển khai phối hợp.

Docker và Microservices gần như đồng nghĩa. Microservices phải là các đơn vị độc lập có thể triển khai riêng biệt, có thể mở rộng. Nhưng nếu bạn tạo nhiều microservices cho ứng dụng của mình thì sao? Docker là một giải pháp nhẹ để triển khai microservices. Một microservice có thể được đóng gói thành một hình ảnh Docker và được cô lập như một vùng chứa Docker - theo cách đó, bạn có thể tạo một ứng dụng độc lập với môi trường máy chủ của mình.

Thay vì có một máy ảo hoàn chỉnh của riêng chúng, các vùng chứa Docker chia sẻ hạt nhân của hệ điều hành trên máy chủ Docker. Các quy trình từ vùng chứa xuất hiện trong bảng quy trình của hệ điều hành mà vùng chứa Docker đang chạy.

Để sử dụng Docker với microservices, bạn cần tạo hình ảnh Docker thông qua các tệp có tên Dockerfile. Dockerfiles rất dễ viết, vì vậy việc triển khai phần mềm có thể dễ dàng. Hãy xem một ví dụ về Dockerfile cho một dịch vụ nhỏ Java:

TỪ openjdk: 11.0.2-jre-slim

SAO CHÉP mục tiêu / khách hàng.jar.

CMD / usr / bin / java -Xmx400m -Xms400m -jar customer.jar

EXPOSE 8080

Bạn muốn tìm hiểu thêm về Docker? Hãy xem khóa học của Educative về kiến ​​thức cơ bản của Docker và Kubernetes .

Một hệ thống microservice điển hình chứa nhiều vùng chứa Docker. Việc điều phối một hệ thống gồm nhiều vùng chứa Docker yêu cầu cấu hình cho mạng ảo. Các vùng chứa phải có thể tìm thấy nhau để giao tiếp. Môi trường Docker Compose có thể liên hệ với máy chủ khác thông qua liên kết, cung cấp hệ thống khám phá dịch vụ.

Tiếp tục học tập.

Tìm hiểu Kiến trúc Microservice mà không cần xem qua video hoặc tài liệu. Các khóa học dựa trên văn bản của Educative rất dễ đọc lướt và có môi trường mã hóa trực tiếp - giúp việc học nhanh chóng và hiệu quả.

Giới thiệu về các Nguyên tắc và Khái niệm Microservice

Ngăn xếp công nghệ và mô hình kiến ​​trúc

Đó là một điều để hiểu cách thức hoạt động của vi kiến ​​trúc và một điều khác để thực sự xây dựng và triển khai nó. Đó là lý do tại sao chúng tôi muốn tập trung vào các công nghệ khác nhau có sẵn cho bạn cho toàn bộ hệ thống microservices. Hãy cùng tìm hiểu một số công nghệ, mẫu và thiết kế khác nhau để tạo ra một kiến ​​trúc microservice có thể thực thi.

Các quyết định về kiến ​​trúc vi mô và vĩ mô

Nên chia kiến ​​trúc của bạn thành kiến ​​trúc vi mô và vĩ mô. Kiến trúc vi mô liên quan đến tất cả các quyết định được thực hiện cho mỗi dịch vụ vi mô. Kiến trúc vĩ mô liên quan đến tất cả các quyết định được đưa ra ở cấp độ toàn cầu áp dụng cho tất cả các dịch vụ vi mô.

Có thể mở rộng khái niệm kiến ​​trúc vi mô và vĩ mô cho các quyết định kỹ thuật. Các quyết định kỹ thuật có thể được thực hiện trong khuôn khổ của kiến ​​trúc vĩ mô hoặc vi mô. Ví dụ: hãy xem các quyết định kỹ thuật được thực hiện ở cấp vi mô và vĩ mô để có cơ sở dữ liệu:

• Micro: Mỗi microservice có thể có phiên bản cơ sở dữ liệu riêng. Nếu cơ sở dữ liệu được xác định theo kiến ​​trúc vi mô, sự cố của một cơ sở dữ liệu sẽ chỉ dẫn đến sự cố của một dịch vụ vi mô. Điều này làm cho ứng dụng mạnh mẽ hơn nhiều.
• Macro: Cơ sở dữ liệu cũng có thể được định nghĩa như một phần của kiến ​​trúc macro. Nhiều dịch vụ nhỏ không được chia sẻ một lược đồ cơ sở dữ liệu.

Hệ thống độc lập [SCS] là một loại kiến ​​trúc dịch vụ vi mô xác định các yếu tố của kiến ​​trúc vĩ mô. Điều này có nghĩa là chúng không đại diện cho toàn bộ hệ thống. Vì một SCS là độc lập, nó cung cấp mọi thứ bạn cần để triển khai một phần của logic miền, chẳng hạn như dữ liệu nhật ký và giao diện người dùng. SCS cũng có một API tùy chọn.

Ví dụ: SCS cho một khoản thanh toán dịch vụ vi mô sẽ lưu trữ thông tin liên quan đến khoản thanh toán đó dưới dạng ngữ cảnh bị ràng buộc. Nó cũng sẽ triển khai giao diện người dùng để hiển thị lịch sử thanh toán và dữ liệu về khách hàng sẽ được sao chép từ các SCS khác.

Hãy coi đây là một tập hợp các phương pháp hay nhất. SCS cung cấp các quy tắc chính xác dựa trên các mẫu đã thiết lập, cung cấp một điểm tham chiếu về cách xây dựng kiến ​​trúc microservice. Tất cả các quy tắc này đảm bảo rằng SCS triển khai một miền, do đó, một tính năng được bổ sung chỉ thay đổi một SCS.

Chúng ta có thể coi SCS như một kiến ​​trúc microservice vì nó có thể được triển khai độc lập và chia hệ thống thành các ứng dụng web độc lập. Trên thực tế, một SCS thậm chí có thể được chia thành nhiều microservices. Chúng khác với microservices ở ba điểm chính: chúng lớn hơn microservices, chúng tập trung vào khớp nối lỏng lẻo và chúng phải có giao diện người dùng.

Bạn có thể tìm hiểu thêm về SCS tại đây .

Tích hợp giao diện người dùng

Microservices cũng có thể được tích hợp với giao diện người dùng web. Việc chia giao diện người dùng thành các mô-đun khác nhau giúp giải quyết một số vấn đề phát sinh từ việc coi nó như một khối nguyên khối. Giao diện người dùng được mô-đun hóa bao gồm các microservices có thể triển khai riêng biệt. Điều này có thể mang lại nhiều lợi ích cho giao diện người dùng của bạn.

Ví dụ: giao diện người dùng được mô-đun hóa có thể có logic miền độc lập và sự thay đổi trong miền có thể được thực hiện đơn giản bằng cách chỉ sửa đổi một microservice. Để kết hợp các giao diện người dùng riêng biệt, chúng phải được tích hợp, vì vậy cần có hệ thống tích hợp.

Điều này có thể được thực hiện thông qua các liên kết, nơi một giao diện người dùng hiển thị một liên kết mà giao diện người dùng khác đọc và xử lý. Điều này cũng có thể được thực hiện thông qua chuyển hướng, chẳng hạn như cách OAuth2 xử lý tích hợp giao diện người dùng. Chuyển hướng kết hợp truyền dữ liệu với tích hợp giao diện người dùng.

Tuy nhiên, có một vài ngoại lệ khi giao diện người dùng nên được triển khai dưới dạng nguyên khối. Ví dụ: các ứng dụng di động gốc phải là các khối triển khai hoặc nếu một nhóm đơn lẻ chịu trách nhiệm phát triển giao diện người dùng thì giao diện người dùng phải được triển khai dưới dạng một khối.

Dịch vụ vi mô không đồng bộ

Các microservices đồng bộ thực hiện một yêu cầu tới các microservices khác trong khi nó xử lý các yêu cầu và chờ đợi kết quả. Các giao thức truyền thông không đồng bộ gửi tin nhắn mà người nhận phản ứng, nhưng không có phản hồi trực tiếp. Một microservice có thể được định nghĩa là không đồng bộ nếu nó không thực hiện yêu cầu tới các microservices khác trong khi xử lý hoặc đưa ra yêu cầu nhưng không đợi kết quả.

Các dịch vụ vi mô không đồng bộ cung cấp một số lợi thế đáng chú ý cho các dịch vụ vi mô đồng bộ và giải quyết nhiều thách thức của hệ thống phân tán. Logic cần thiết để xử lý các yêu cầu microservice không phụ thuộc vào kết quả, khiến chúng độc lập hơn nhiều.

Tương tự như vậy, nếu một đối tác truyền thông bị lỗi, nó không làm hỏng toàn bộ hệ thống, mang lại khả năng phục hồi tổng thể cho hệ thống của bạn. Hơn hết, việc xử lý và giao hàng gần như luôn được đảm bảo.

Một số ví dụ phổ biến về công nghệ cho các dịch vụ vi mô không đồng bộ là Kafka [một MOM thường được sử dụng để nhắn tin], định dạng dữ liệu REST và Atom [cho cơ sở hạ tầng bổ sung].

Nền tảng microservices

Các nền tảng microservice, chẳng hạn như bộ lập lịch PaaS và Docker, hỗ trợ hoạt động và giao tiếp của các microservices của bạn. Những công nghệ này cho phép giao tiếp giữa các microservices để triển khai, phân tích nhật ký và giám sát.

Ví dụ: các nền tảng này hỗ trợ HTTP và REST với tính năng cân bằng tải và khám phá dịch vụ. Hỗ trợ hoạt động hạn chế là cần thiết để triển khai các dịch vụ nhỏ, để chúng có thể được triển khai nhanh chóng và hỗ trợ nhiều dịch vụ vi mô.

Nền tảng Microservices đại diện cho sự đơn giản hóa và giải pháp cho các vấn đề chung. Một số nền tảng đáng chú ý là Kubernetes và Docker - rất quan trọng đối với các hoạt động của microservices. PaaS và Cloud Foundry cũng hữu ích nhưng không phổ biến bằng.

Điều quan trọng cần lưu ý là việc di chuyển sang các nền tảng này yêu cầu thay đổi hoạt động và cài đặt ứng dụng, điều này có thể làm cho việc sử dụng nền tảng microservices trở thành một bước tiến lớn và kịp thời. Đây là nhược điểm chính của các nền tảng microservice.

Kết thúc

Bây giờ bạn đã biết kiến ​​trúc microservices phải cung cấp những gì và có những biến thể nào, bạn đã sẵn sàng để bắt đầu với một số bài học thực hành. Hãy xem danh sách tài nguyên của chúng tôi bên dưới để biết thêm thông tin về microservices.

Tài nguyên

• Hướng dẫn về microservices : tập hợp các bài báo đề cập đến nhiều chủ đề khác nhau liên quan đến microservices.
• Nghệ thuật giám sát trong thời đại của các dịch vụ vi mô: một câu hỏi và đáp hữu ích với tác giả của "Nghệ thuật giám sát" bao gồm các chiến lược giám sát.
• Xây dựng Microservices:: cuốn sách của O'Reilly về microservices.
• GitHub's Beginner Guide to Microservices: dễ dàng điều hướng kho mã cho người mới bắt đầu.
• AWS Intro to Microservices: Tài liệu và định nghĩa của Amazon về các khái niệm microservice.

Tìm kiếm một khóa học trực tuyến mà bạn thực sự có thể tin tưởng? Chúng tôi đã giới thiệu cho bạn loạt bài về dịch vụ vi mô gồm hai phần, tất cả những gì bạn cần biết được viết bởi một trong những chuyên gia trong lĩnh vực này, Eberhard Wolff, một thành viên sáng lập của cộng đồng Java Champions.

Bắt đầu với các nguyên tắc cơ bản của microservices để tìm hiểu tất cả các nền tảng cần thiết cho việc triển khai và thực hiện.

Giới thiệu về các Nguyên tắc và Khái niệm Microservice sẽ hướng dẫn bạn qua tất cả những ưu và nhược điểm của xu hướng thú vị này bằng cách sử dụng các ví dụ và chiến lược di chuyển trong thế giới thực.

Sau đó, bạn có thể chuyển sang Kiến trúc Microservice: Triển khai thực tế , một trong những khóa học tốt nhất về các chi tiết thực tế của việc triển khai trong thế giới thực.

Khóa học này sẽ hướng dẫn bạn qua các công thức nấu ăn trong thế giới thực và các kho công nghệ. Bạn sẽ điều hướng từ đầu đến cuối của việc triển khai và trở thành một chuyên gia dịch vụ vi mô cuối cùng!

Cả hai khóa học này đều dựa trên cuốn sách được đánh giá cao của Eberhard về cùng một chủ đề, vì vậy bạn biết mình đang được hướng dẫn hàng đầu. Hãy trang bị tốt hơn để đối phó với xu hướng đang phát triển này!

Chúc bạn học vui vẻ!

Video liên quan