Triển khai Microservice: Spring Cloud vs. Kubernetes

toannm

Spring Cloud và Kubernetes đều tuyên bố mình là môi trường phát triển và chạy microservice tốt nhất, nhưng cả hai rất khác nhau về bản chất và đều giải quyết các mối quan tâm khác nhau. Bài viết này sẽ xem xét cách mỗi platform hỗ trợ như thế nào trong việc cung cấp các kiến trúc dựa trên microservice (MSA), lĩnh vực nào chúng giỏi và cách sử dụng tốt nhất của cả hai môi trường để thành công trong hành trình của Microservice.

Bối cảnh

Có một bài viết khá hay về việc xây dựng Kiến trúc microservice với Spring Cloud và Docker của A. Lukyanchikov. Nên đọc bài viết này, vì nó cung cấp một cái nhìn tổng quan toàn diện về những gì nó cần để tạo ra một hệ thống dựa trên microservice đơn giản bằng Spring Cloud. Để xây dựng một hệ thống microservice có khả năng mở rộng và có khả năng phục hồi có thể phát triển lên hàng chục hoặc hàng trăm dịch vụ, nó phải được quản lý tập trung và quản lý với sự trợ giúp của một bộ công cụ có build time và runtime rộng rãi. Với Spring Cloud, liên quan đến việc triển khai cả dịch vụ chức năng (như dịch vụ thống kê, dịch vụ tài khoản và dịch vụ thông báo) và các dịch vụ cơ sở hạ tầng hỗ trợ (như phân tích nhật ký, máy chủ cấu hình, khám phá dịch vụ, dịch vụ xác thực). Một sơ đồ mô tả MSA như vậy bằng Spring Cloud sẽ như bên dưới:

365c0d94-eefa-11e5-90ad-9d74804ca412-2.png

MSA với Spring Cloud (của A. Lukyanchikov)

Sơ đồ này bao gồm các khía cạnh runtime của hệ thống, nhưng nó không nói gì đến package, tích hợp liên tục, nhân rộng, tính sẵn sàng cao và tự phục hồi, những thứ cũng rất quan trọng trong thế giới MSA. Giả sử rằng phần lớn các nhà phát triển Java đã quen thuộc với Spring Cloud, bài viết này sẽ phân tích song song và xem Kubernetes liên quan đến Spring Cloud bằng cách giải quyết các mối quan tâm bổ sung này.

Mối quan tâm của microservice

Thay vì thực hiện một tính năng bằng cách so sánh tính năng, hãy xem xét các mối quan tâm của microservice rộng hơn và xem Spring Cloud và Kubernetes tiếp cận chúng như thế nào. Điểm tốt của MSA ngày nay là phong cách kiến trúc với những lợi ích và sự đánh đổi được hiểu rõ. Microservice cho phép ranh giới module mạnh mẽ, với sự đa dạng công nghệ và triển khai độc lập. Nhưng nó phải trả giá bằng việc phát triển các hệ thống phân tán và chi phí hoạt động đáng kể. Một yếu tố thành công chính là tập trung vào việc được bao quanh bởi các công cụ sẽ giúp người dùng giải quyết càng nhiều mối quan tâm của MSA càng tốt. Làm cho quá trình bắt đầu trở nên nhanh chóng và dễ dàng là rất quan trọng, nhưng hành trình sản xuất là một chặng đường dài, và người dùng cần phải có những nền tảng cần thiết để đạt được điều đó.

Screen Shot 2016-12-03 at 09.32.38.png

Mối quan tâm của microservice

Trong sơ đồ trên, có thể thấy một danh sách với các mối quan tâm về kỹ thuật phổ biến nhất (không đề cập đến các mối quan tâm phi kỹ thuật như cấu trúc tổ chức, văn hóa, v.v.) phải được giải quyết trong MSA.

Bản đồ công nghệ

Hai platform, Spring Cloud và Kubernetes, rất khác nhau và không có tính năng tương đương trực tiếp giữa chúng. Nếu ánh xạ từng mối quan tâm của MSA đến công nghệ / dự án được sử dụng để giải quyết nó trong cả hai platform, sẽ có bảng như bên dưới.

Screen Shot 2016-11-30 at 08.45.11.png

Công nghệ Spring Cloud và Kubernetes

Tóm tắt chính từ bảng trên là:

  • Spring Cloud có một bộ thư viện Java tích hợp tốt để giải quyết tất cả các mối quan tâm về runtime như là một phần của ngăn xếp ứng dụng. Do đó, bản thân các dịch vụ microservice có các thư viện và tác nhân runtime để khám phá dịch vụ phía máy khách, cân bằng tải, cập nhật cấu hình, theo dõi số liệu, v.v. Các mẫu như dịch vụ cụm đơn và các công việc hàng loạt cũng được quản lý trong JVM.
  • Kubernetes là polyglot, không chỉ dành cho các platform Java và giải quyết các thách thức điện toán phân tán theo cách chung cho tất cả các ngôn ngữ. Nó cung cấp các dịch vụ để quản lý cấu hình, khám phá dịch vụ, cân bằng tải, theo dõi, số liệu, singletons, các công việc được lên lịch ở cấp độ platform và application stack. Ứng dụng không cần bất kỳ thư viện hoặc tác nhân nào cho logic phía máy khách và nó có thể được viết bằng bất kỳ ngôn ngữ nào.
  • Trong một số lĩnh vực, cả hai platform đều dựa trên các công cụ của bên thứ ba tương tự. Ví dụ: ngăn xếp ELK và EFK, thư viện theo dõi, v.v ... Một số thư viện, chẳng hạn như Hystrix và Spring Boot, cũng hữu ích như nhau trên cả hai môi trường. Có những khu vực mà cả hai platform là bổ sung và có thể được kết hợp với nhau để tạo ra một giải pháp mạnh mẽ hơn (VD như là KubeFlix và Spring Cloud Kubernetes).

Yêu cầu của microservice

Để thể hiện phạm vi của từng dự án, đây là một bảng với (hầu hết) các yêu cầu MSA từ đầu đến cuối bắt đầu từ phần cứng ở dưới cùng, cho đến DevOps và trải nghiệm tự phục vụ ở trên cùng và cách nó liên quan đến các platform Spring Cloud và Kubernetes.

Screen Shot 2016-12-03 at 14.09.41.png

Yêu cầu của microservice

Trong một số trường hợp, cả hai platform đều giải quyết các yêu cầu giống nhau bằng cách sử dụng các cách tiếp cận khác nhau và trong một số lĩnh vực, một platform có thể mạnh hơn platform kia. Nhưng cũng có một điểm là khi cả hai platform đều bổ sung cho nhau và có thể được kết hợp để có trải nghiệm microservice vượt trội. Ví dụ, Spring Boot cung cấp các plugin Maven để xây dựng các gói ứng dụng JAR duy nhất. Điều đó, kết hợp với các khả năng Triển khai và Lập lịch khai báo của Docker và Kubernetes, giúp cho việc chạy microservice trở nên dễ dàng. Tương tự, Spring Cloud có các thư viện trong ứng dụng để tạo các microservice có khả năng chịu lỗi, sử dụng Hystrix (với các mẫu vách ngăn và bộ ngắt mạch) và Ribbon (để cân bằng tải). Nhưng một mình nó thì không đủ, và khi nó được kết hợp với health checks của Kubernetes, xử lý khởi động lại và khả năng tự động mở rộng, thì microservice trở thành một hệ thống chống đông thực sự.

Điểm mạnh và điểm yếu

Vì cả hai platform không thể so sánh trực tiếp từng tính năng một và thay vì đào sâu vào từng mục, đây là những ưu điểm và nhược điểm (tóm tắt) của từng platform.

Spring Cloud

Spring Cloud cung cấp các công cụ cho các nhà phát triển để nhanh chóng xây dựng một số mẫu phổ biến trong các hệ thống phân tán như quản lý cấu hình, khám phá dịch vụ, ngắt mạch, định tuyến, v.v. Nó được xây dựng trên các thư viện OSS của Netflix, viết bằng Java, cho các nhà phát triển Java.

Điểm mạnh

  • Mô hình lập trình hợp nhất do chính Spring Platform cung cấp và khả năng tạo ứng dụng nhanh chóng của Spring Boot mang đến cho các nhà phát triển trải nghiệm phát triển microservice tuyệt vời. Ví dụ: chỉ với một vài chú thích, người dùng có thể tạo Máy chủ Cấu hình và với một vài chú thích nữa, họ có thể lấy các thư viện máy khách để định cấu hình dịch vụ của mình.
  • Có nhiều lựa chọn thư viện bao gồm phần lớn các mối quan tâm về runtime. Vì tất cả các thư viện được viết bằng Java, nó cung cấp nhiều tính năng, kiểm soát tốt hơn và các tùy chọn tinh chỉnh.
  • Các thư viện Spring Cloud khác nhau được tích hợp tốt với nhau. Ví dụ, một máy khách cũng sẽ sử dụng Hystrix cho Circuit Breaking và Ribbon cho các yêu cầu cân bằng tải. Mọi thứ đều được chú thích điều khiển, giúp dễ dàng phát triển cho các nhà phát triển Java.

Những điểm yếu

  • Một trong những ưu điểm chính của Spring Cloud cũng là nhược điểm của nó - nó chỉ giới hạn ở Java. Một động lực mạnh mẽ cho MSA là khả năng trao đổi các ngăn xếp công nghệ, thư viện và thậm chí các ngôn ngữ khi được yêu cầu. Điều đó là không thể với Spring Cloud. Nếu người dùng muốn sử dụng các dịch vụ cơ sở hạ tầng Spring Cloud / Netflix OSS, chẳng hạn như quản lý cấu hình, khám phá dịch vụ hoặc cân bằng tải thì giải pháp này sẽ không hiệu quả. Dự án Netflix Prana triển khai mẫu sidecar để hiển thị các thư viện máy khách dựa trên Java qua HTTP để cho phép các ứng dụng được viết bằng các ngôn ngữ không phải JVM tồn tại trong hệ sinh thái NetflixOSS, nhưng nó không hiệu quả cho lắm.
  • Có quá nhiều trách nhiệm cho các nhà phát triển Java quan tâm và xử lý các ứng dụng Java. Mỗi microservice cần chạy các máy khách khác nhau để truy xuất cấu hình, khám phá dịch vụ và cân bằng tải. Thật dễ dàng để thiết lập chúng, nhưng điều đó không che giấu sự phụ thuộc thời gian xây dựng và runtime vào môi trường. Ví dụ: nhà phát triển có thể tạo Config Server với @EnableConfigServer, nhưng đó chỉ là cách dễ dàng nhất. Mỗi khi các nhà phát triển muốn chạy một microservice duy nhất, họ cần phải có Config Server hoạt động. Đối với một môi trường được kiểm soát, các nhà phát triển phải suy nghĩ về việc làm cho Config Server có sẵn cao và vì nó có thể được hỗ trợ bởi Git hoặc Svn, nên họ cần một hệ thống tệp chia sẻ cho nó. Tương tự, để khám phá dịch vụ, các nhà phát triển cần khởi động máy chủ Eureka trước. Đối với một môi trường được kiểm soát, họ cần phân cụm nó với nhiều phiên bản trên mỗi AZ, v.v. Cảm giác như một nhà phát triển Java phải xây dựng và quản lý một platform microservice không tầm thường bên cạnh việc triển khai tất cả các dịch vụ chức năng.
  • Spring Cloud có phạm vi ngắn hơn trong hành trình microservice và các nhà phát triển cũng cần xem xét triển khai tự động, lập lịch, quản lý tài nguyên, cách ly quy trình, tự phục hồi, xây dựng pipeline, v.v. để có trải nghiệm microservice hoàn chỉnh. Về điểm này, thật không công bằng khi so sánh Spring Cloud với Kubernetes và một so sánh công bằng hơn sẽ là giữa Spring Cloud + Cloud Foundry (hoặc Docker Swarm) và Kubernetes. Nhưng điều đó cũng có nghĩa là để có trải nghiệm microservice hoàn chỉnh từ đầu đến cuối, Spring Cloud phải được bổ sung một platform ứng dụng như chính Kubernetes.

Kubernetes

Kubernetes là một hệ thống nguồn mở để tự động hóa việc triển khai, nhân rộng và quản lý các ứng dụng được đóng gói. Nó là polyglot và cung cấp các nguyên hàm để cung cấp, chạy, nhân rộng và quản lý các hệ thống phân tán.

Điểm mạnh

  • Kubernetes là một platform quản lý container đa âm và đa ngôn ngữ, có khả năng chạy cả các ứng dụng được chứa trong các ứng dụng được đóng gói cloud native và truyền thống. Các dịch vụ mà nó cung cấp, chẳng hạn như quản lý cấu hình, khám phá dịch vụ, cân bằng tải, thu thập số liệu và tổng hợp nhật ký, có thể sử dụng được bằng nhiều ngôn ngữ. Điều này cho phép có một platform trong tổ chức có thể được sử dụng bởi nhiều nhóm (bao gồm cả các nhà phát triển Java sử dụng Spring) và phục vụ nhiều mục đích: phát triển ứng dụng, môi trường thử nghiệm, xây dựng môi trường (để chạy hệ thống kiểm soát nguồn, xây dựng máy chủ, kho lưu trữ giả), v.v. .
  • Khi so sánh với Spring Cloud, Kubernetes giải quyết một loạt các mối quan tâm MSA rộng hơn. Ngoài việc cung cấp dịch vụ runtime, Kubernetes còn cho phép người dùng cung cấp môi trường, thiết lập các ràng buộc tài nguyên, RBAC, quản lý vòng đời ứng dụng, cho phép tự động hóa và tự phục hồi (hoạt động gần giống như một platform chống đông).
  • Công nghệ Kubernetes dựa trên 15 năm nghiên cứu và phát triển của Google và kinh nghiệm quản lý các container. Ngoài ra, với gần 1000 thành viên, đây là một trong những cộng đồng Nguồn mở tích cực nhất trên Github.

Điểm yếu

  • Kubernetes là polyglot và, do đó, các dịch vụ và nguyên thủy của nó là chung chung và không được tối ưu hóa cho các platform khác nhau như Spring Cloud cho JVM. Ví dụ, các cấu hình được truyền cho các ứng dụng dưới dạng các biến môi trường hoặc một hệ thống tệp được gắn kết. Nó không có khả năng cập nhật cấu hình ưa thích được cung cấp bởi Spring Cloud Config.
  • Kubernetes không phải là một platform tập trung vào nhà phát triển. Nó được dự định sẽ được sử dụng bởi các nhân viên IT có tư tưởng DevOps. Như vậy, các nhà phát triển Java cần học một số khái niệm mới và sẵn sàng học hỏi các cách giải quyết vấn đề mới. Mặc dù để bắt đầu một phiên bản phát triển của Kubernetes bằng MiniKube rất dễ dàng, nhưng chi phí hoạt động để cài đặt một cụm Kubernetes có sẵn cao theo cách thủ công khá lớn.
  • Kubernetes vẫn là một platform tương đối mới (2 năm tuổi) và nó vẫn đang được tích cực phát triển. Do đó, có nhiều tính năng mới được thêm vào với mỗi bản phát hành mà có thể khó theo kịp. Tin tốt là điều này nằm trong dự tính và API có thể mở rộng và tương thích ngược.

Điểm mạnh của cả 2 platform

Như đã thấy, cả hai platform đều có thế mạnh ở một số điểm nhất định và những điều cần cải thiện ở các điểm khác. Spring Cloud bắt đầu nhanh chóng với platform thân thiện với nhà phát triển, trong khi Kubernetes thân thiện với DevOps, với đường cong học tập dốc hơn, nhưng bao trùm một loạt các mối quan tâm của microservice. Dưới đây là một bản tóm tắt về những điểm đó.

Screen Shot 2016-12-03 at 15.45.54.png

Điểm mạnh và điểm yếu

Cả hai framework giải quyết một loạt các mối quan tâm khác nhau của MSA và chúng về cơ bản thực hiện nó theo những cách khác nhau. Cách tiếp cận Spring Cloud đang cố gắng giải quyết mọi thách thức MSA bên trong JVM, trong khi cách tiếp cận Kubernetes đang cố gắng làm cho vấn đề biến mất cho các nhà phát triển bằng cách giải quyết nó ở cấp độ platform. Spring Cloud rất mạnh bên trong JVM và Kubernetes rất mạnh trong việc quản lý các JVM đó. Như vậy, có vẻ như đó là một sự tiến bộ tự nhiên để kết hợp chúng và hưởng lợi từ các phần tốt nhất của cả hai platform.

spring cloud and kubernetes mixed - Page 1(1).png

Spring Cloud được hỗ trợ bởi Kubernetes

Với sự kết hợp như vậy, Spring cung cấp package ứng dụng và Docker và Kubernetes cung cấp việc triển khai và lên lịch. Spring cung cấp vách ngăn trong ứng dụng thông qua nhóm luồng Hystrix và Kubernetes cung cấp vách ngăn thông qua cách ly tài nguyên, quy trình và namespace. Spring cung cấp health endpoint cho mọi microservice và Kubernetes thực hiện health checks và định tuyến lưu lượng truy cập đến các healthy services. Spring ngoại vi hóa và cập nhật các cấu hình, và Kubernetes phân phối các cấu hình cho mọi microservice. Và quy trình này cứ tiếp tục như vậy.

stack - Page 1.png

Ngăn xếp microservice yêu thích của tác giả

Dưới góc nhìn cá nhân của tác giả, cả hai platform đều rất tuyệt . Người viết thích trải nghiệm của nhà phát triển được cung cấp bởi Spring framework. Đó là tất cả các chú thích điều khiển, và có các thư viện bao gồm tất cả các loại yêu cầu chức năng. Tác giả cũng thích Apache Camel (hơn là Spring Integration) cho mọi thứ liên quan đến tích hợp, trình kết nối, nhắn tin, định tuyến, khả năng phục hồi và khả năng chịu lỗi ở cấp ứng dụng. Sau đó, để làm bất cứ điều gì với việc phân cụm và quản lý nhiều trường hợp ứng dụng, Kubernetes được người viết ưa dùng hơn. Và bất cứ khi nào có sự chồng chéo về chức năng, chẳng hạn như để khám phá dịch vụ, cân bằng tải, quản lý cấu hình, tác giả khuyên dùng sử dụng các nguyên hàm polyglot do Kubernetes cung cấp.
 
Top