Đừng tin vào những lời cường điệu: 5 nhược điểm của microservices

Kiến trúc microservice là một mẫu phần mềm sắp xếp một ứng dụng dưới dạng một tập hợp các dịch vụ được kết hợp lỏng lẻo giao tiếp thông qua các giao thức nhẹ. Những người ủng hộ microservice lập luận rằng các giao diện cách ly và mỏng mang lại tính tùy chọn trong việc triển khai và khả năng kết hợp.

Nhưng microservices không phải lúc nào cũng là giải pháp kỳ diệu như chúng tuyên bố.

Trong bài đăng này, chúng ta sẽ xem xét những ưu điểm và nhược điểm của vi dịch vụ cũng như cách đánh giá xem kiến ​​trúc vi dịch vụ có phù hợp với bạn hay không.

Mục lục

1. microservice là gì
2. Ưu điểm của microservice
3. 5 nhược điểm của microservice
4. Microservice có phù hợp với bạn không?

microservice là gì?

Microservices là một cách tiếp cận kiến ​​trúc trong đó một ứng dụng duy nhất bao gồm nhiều thành phần hoặc dịch vụ nhỏ hơn có thể triển khai độc lập và được ghép nối lỏng lẻo. Cách tiếp cận kiến ​​trúc này có thể được mô tả dựa trên các tính năng sau:

• Ngăn xếp công nghệ cá nhân. Mỗi dịch vụ có ngăn xếp công nghệ riêng, bao gồm cơ sở dữ liệu và mô hình quản lý dữ liệu.
• Sự phụ thuộc vào các giao thức truyền thông. Các dịch vụ giao tiếp với nhau bằng các giao thức giao tiếp, chẳng hạn như API tài nguyên HTTP và nhắn tin không đồng bộ nhẹ.
• Tổ chức theo năng lực kinh doanh. Các dịch vụ được tổ chức theo khả năng kinh doanh, với các dịch vụ phân tách dòng thường được gọi là bối cảnh có giới hạn. Ví dụ: trong thương mại điện tử, mọi thứ liên quan đến quản lý khách hàng sẽ nằm trong một ngữ cảnh giới hạn.

Ưu điểm của microservice

Một kiến ​​trúc microservice tối ưu hóa để phân tách các mối quan tâm và sự phối hợp. Những thuộc tính này cung cấp cho các nhóm kỹ thuật sự lựa chọn và quyền tự chủ. Đây là lý do tại sao nhiều tổ chức chọn xây dựng bằng microservice.

Một số lợi ích kỹ thuật chính của kiến ​​trúc microservice bao gồm:

• Linh hoạt và nhanh nhẹn. Mã có thể được cập nhật dễ dàng, với các tính năng và chức năng mới được triển khai mà không cần chạm vào toàn bộ ứng dụng. Điều này cũng cho phép các nhóm triển khai các bản cập nhật một cách chi tiết và thử nghiệm nhanh chóng.
• Quyền tự trị. Ở cấp độ mã, các nhà phát triển và nhóm có thể làm việc độc lập và tùy ý sử dụng kết hợp các công cụ và khuôn khổ khác nhau. Nó cũng cho phép các nhóm triển khai các bản cập nhật một cách chi tiết.
• Khả năng mở rộng. Các thành phần có thể được chia tỷ lệ độc lập với nhau mà không cần phải chia tỷ lệ toàn bộ ứng dụng.

5 nhược điểm chính của microservice

Dịch vụ vi mô đi kèm với chi phí và sự đánh đổi đáng kể khi được áp dụng tự do: bạn mua tùy chọn bằng cách trả tiền cho sự phát triển riêng biệt và bảo trì liên tục.

Hầu hết, nếu không muốn nói là tất cả, những lợi thế của microservices có thể đạt được với một nền tảng có thể mở rộng. Một hạt nhân được xây dựng tốt cung cấp năng lượng cho nền tảng có thể cung cấp một tập hợp các hợp đồng và API được kết hợp chặt chẽ, cho phép nền tảng mang lại lợi ích về tốc độ, sự gắn kết và bảo trì thấp, đồng thời cho phép khả năng mở rộng và cấu hình mô-đun khi cần.

Dưới đây, chúng ta sẽ xem xét những nhược điểm chính của kiến ​​trúc vi dịch vụ—và cách một nền tảng có thể mang lại giá trị tương tự trong khi giảm thiểu một số cạm bẫy phổ biến của vi dịch vụ:

1. Tăng chi phí bảo trì
2. Sự phức tạp của tổ chức và chi phí
3. Phối hợp phức tạp
4. Rủi ro thất bại
5. Các vấn đề về hiệu suất và độ tin cậy

1. Tăng chi phí bảo trì

Sự nhanh nhẹn và linh hoạt của microservice tạo ra sự phức tạp trong hoạt động và tăng chi phí bảo trì. Điều đó không có nghĩa là các nhóm kỹ thuật cần phải từ bỏ khả năng mở rộng và khả năng kết hợp.

Sự kết hợp và phân tách cấp độ dịch vụ mạnh mẽ là chìa khóa cho kiến ​​trúc doanh nghiệp linh hoạt và có thể mở rộng, được tạo ra tốt nhất thông qua việc sử dụng cơ sở hạ tầng dùng chung, mã nguyên thủy và hợp đồng dịch vụ. Điều này cho phép các nhóm hoạt động trên các dịch vụ với ngữ cảnh và công cụ có thể tái sử dụng, đồng thời cho phép các nhóm bảo mật thực thi các bảo đảm trên toàn hệ thống.

Khả năng mở rộng và khả năng kết hợp là thuộc tính của thiết kế hệ thống, không phải là lựa chọn cụ thể để sử dụng microservice.

Microservices không phải là con đường duy nhất để mở rộng. Phần mở rộng và trình điều khiển hạt nhân là các mẫu mang lại lợi ích của nền tảng—tốc độ, tính gắn kết và bảo trì thấp—đồng thời cho phép khả năng mở rộng và cấu hình mô-đun.

Phần mở rộng kernel cho phép khả năng ghép nối giữa các dịch vụ kernel lõi, đồng thời cho phép tùy chỉnh nội tuyến hành vi hoặc logic của nó. Hoàn thành tốt, logic được cung cấp sẽ được thực thi trong một thời gian chạy an toàn, được tối ưu hóa và được quản lý giúp loại bỏ sự đánh đổi giữa khả năng phối hợp, tốc độ và khả năng mở rộng. Mặt khác, các trình điều khiển cung cấp khả năng tích hợp chặt chẽ cao với nhân và cung cấp cho hệ điều hành các khả năng mới.

2. Độ phức tạp của tổ chức và chi phí hoạt động

Microservices cho phép các nhà phát triển làm việc độc lập bằng cách sử dụng bất kỳ công cụ và khung nào họ muốn. Họ có thể linh hoạt các kỹ năng của mình và triển khai các giải pháp một cách nhanh chóng. Nhưng đối với các nhà lãnh đạo doanh nghiệp, có một chi phí chung để có mức độ tự chủ cao của nhóm.

Bạn cần phân chia trách nhiệm rõ ràng và thông số kỹ thuật chi tiết về sự tương tác giữa các dịch vụ siêu nhỏ sẽ như thế nào và chúng sẽ được quản lý lâu dài như thế nào và bởi ai. Nếu không chọn, bạn sẽ mất đòn bẩy hoạt động và lợi ích của các tiêu chuẩn, mẫu và kiến ​​thức được chia sẻ giữa các nhóm.

Điều này dẫn đến chi phí kỹ thuật tăng cao, thêm các lớp quản lý cấp trên và các ngăn xếp kỹ thuật kiểu Byzantine có chức năng chỉ những người viết triển khai mới hiểu được.

3. Phối hợp phức tạp

Chi phí được thừa nhận của microservice là bạn đang duy trì và điều phối nhiều phần chuyển động hơn. Và mặc dù các dịch vụ có thể được triển khai riêng lẻ, nhưng chúng phải phối hợp với nhau để đạt được mục tiêu mong muốn. Sự phụ thuộc giữa các dịch vụ thường dẫn đến việc triển khai phức tạp và dễ vỡ.

Kiến trúc tốt thúc đẩy sự cô lập thành phần và dịch vụ ở những nơi thích hợp. Quá nhiều thứ đó—một cạm bẫy phổ biến trong microservices—có thể dẫn đến các triển khai dễ vỡ, khó kiểm tra, thay đổi quy mô và gỡ lỗi.

???? câu chuyện thận trọng

Ví dụ: khi Airbnb chuyển sang kiến ​​trúc hướng dịch vụ để loại bỏ sự phức tạp nguyên khối, họ nhận thấy cách tiếp cận dựa trên vi dịch vụ của mình đã dẫn đến một mớ phức tạp của chính nó. Công ty hiện có 2.000 dịch vụ, được quản lý bởi 500 kỹ sư. Jessica Tai, giám đốc kỹ thuật hàng đầu của Airbnb và kỹ sư cơ sở hạ tầng dịch vụ cốt lõi, cho biết: “Khó có thể lý luận về biểu đồ phụ thuộc.

Sự phức tạp như vậy khiến nhóm Airbnb gặp khó khăn trong việc gỡ lỗi dịch vụ. Việc phát triển các tính năng cũng mất nhiều thời gian hơn do ngày càng có nhiều thay đổi phải thực hiện tại các điểm tích hợp, các dịch vụ bắt đầu sao chép chức năng và dữ liệu ngày càng bị phân mảnh.

4. Rủi ro thất bại tầng

Sự phổ biến của các dịch vụ—mỗi dịch vụ có đặc điểm triển khai, kiến ​​trúc và hiệu suất riêng—làm tăng đáng kể nguy cơ xảy ra các tầng lỗi không mong muốn, điều này đòi hỏi phải có khả năng gỡ lỗi và theo dõi dịch vụ chéo hoàn thiện.

Các nền tảng thành công nhất đi kèm với một tập hợp nguyên thủy, quy trình làm việc và các phương pháp hay nhất được tuyển chọn sẵn được mã hóa bên trong. Những ý kiến ​​được thiết kế tốt dẫn đến kết quả tốt hơn và thành công cho những người áp dụng chúng.

Một API được thiết kế tốt và sự trừu tượng hóa có ý kiến ​​mã hóa các phương pháp hay nhất và cho phép triển khai dễ dàng, có thể mở rộng. Ví dụ: một ngôn ngữ tạo khuôn mẫu có ý kiến ​​có thể loại bỏ hiệu quả cross-site scripting (XSS) và các cuộc tấn công bảo mật phía máy khách đầy rẫy tương tự. Hoặc, ít nhất, làm cho các cuộc tấn công này rất khó thực hiện. Một thời gian chạy được quản lý với các giới hạn thực thi, bộ nhớ đệm, thử lại và bộ ngắt mạch cũng có thể cung cấp một hợp đồng mạnh mẽ và đảm bảo cho hiệu suất có thể dự đoán được trong điều kiện tải cực lớn.

Những ý kiến ​​hay, được mã hóa trong các nền tảng và SDK, là trợ thủ đắc lực cho nhà phát triển. Chúng trừu tượng hóa các chức năng và nhu cầu chung đằng sau các giao diện tiêu chuẩn, hạn chế và loại bỏ các mẫu và lựa chọn xấu, đẩy nhanh lộ trình dẫn đến giá trị và giảm thiểu chi phí phát triển và bảo trì.

5. Các vấn đề về hiệu suất và độ tin cậy

Microservices cung cấp toàn bộ tùy chọn trong việc lựa chọn công nghệ. Tuy nhiên, chi phí quản lý thông tin liên lạc giữa các dịch vụ khác nhau là một nút cổ chai hiệu suất phổ biến.

???? câu chuyện thận trọng

Steve Cosenza, cựu kỹ sư nhân viên cấp cao của Twitter, giải thích điều gì sẽ xảy ra khi các nhóm độc lập thiết kế và xây dựng điểm cuối cho các trường hợp sử dụng cụ thể của họ mà không có sự phối hợp chặt chẽ: “Microservice dẫn đến sự phân mảnh và chắc chắn là làm chậm năng suất của nhà phát triển. Mặc dù lúc đầu, cách tiếp cận microservices cho phép tăng tốc độ phát triển, nhưng nó cũng dẫn đến API Twitter phân tán và rời rạc.”

Việc không có quy ước mã dùng chung hoặc SDK làm tăng rủi ro bảo mật và chi phí kiểm toán, đồng thời sự không tương thích về phiên bản và API tinh vi có thể dẫn đến sự cố người dùng thất thường và khó gỡ lỗi.

Giải quyết những thách thức này đòi hỏi phải có một nền văn hóa kỹ thuật trưởng thành, bao gồm các kỹ sư giàu kinh nghiệm biết cách gỡ lỗi một ứng dụng phân tán, phức tạp và một nhóm vận hành và độ tin cậy có nhân viên tốt, cũng như đầu tư vào kỹ thuật bảo trì và khả năng phục hồi liên tục.

Microservice có phù hợp với bạn không? (Cảnh báo spoiler: Có lẽ là không)

Microservices cho phép bạn mua thêm một lớp linh hoạt. Từ tác dụng là “mua.”

Microservices không miễn phí—chúng nổi tiếng là tốn kém để xây dựng và duy trì. Nếu bạn là Amazon hoặc Netflix và bạn cần sự linh hoạt bổ sung đó, chi phí này cuối cùng sẽ tự trả. Với các doanh nghiệp phức tạp ở quy mô này, microservice chắc chắn đáng được xem xét.

Nhưng thường xuyên hơn không, các dịch vụ siêu nhỏ chỉ gây ra chi phí và độ phức tạp không cần thiết, khiến các tổ chức phải thiết kế quá mức hệ thống công nghệ của họ và rút tài nguyên ra khỏi các dự án mang lại giá trị cho khách hàng.

Phần lớn các doanh nghiệp sẽ tốt hơn với nền tảng thương mại mạnh mẽ có thể mang lại lợi ích về tốc độ, sự gắn kết và bảo trì thấp, đồng thời cho phép khả năng mở rộng và cấu hình mô-đun với các thành phần dựng sẵn khi cần.

Shopify là—và luôn luôn là—nền tảng dưới dạng dịch vụ (PaaS). Sản phẩm của nó là một thời gian chạy được quản lý cung cấp khả năng mở rộng chức năng, thành phần mô-đun, một bộ dịch vụ thương mại lớn và đang phát triển Và Các khả năng do 3P phát triển có thể hỗ trợ các nhu cầu riêng của nhà bán lẻ.

Mặc dù không có công thức duy nhất để thành công, nhưng một nền tảng được xây dựng tốt có thể giảm thiểu công việc, chi phí và rủi ro, đồng thời đẩy nhanh thời gian đưa sản phẩm ra thị trường và cho phép các doanh nghiệp vận dụng chuyên môn kỹ thuật của mình vào những lĩnh vực thực sự quan trọng: trở nên không thể thiếu đối với khách hàng của họ.

Để biết thêm thông tin về cách đánh giá kiến ​​trúc thương mại phù hợp cho doanh nghiệp bán lẻ doanh nghiệp của bạn, tải về whitepaper của chúng tôi Nguyên tắc của một hệ điều hành thương mại hiện đại.