Ngày 19 tháng XNUMX tại Mátxcơva cuộc họp chuyên đề đầu tiên HUG (Nhóm người dùng Highload++), dành riêng cho microservice. Có một bài thuyết trình “Vận hành vi dịch vụ: Vấn đề về kích thước, ngay cả khi bạn có Kubernetes”, trong đó chúng tôi đã chia sẻ kinh nghiệm sâu rộng của Flant trong việc vận hành các dự án có kiến trúc vi dịch vụ. Trước hết, nó sẽ hữu ích cho tất cả các nhà phát triển đang nghĩ đến việc sử dụng phương pháp này trong dự án hiện tại hoặc tương lai của họ.
Giới thiệu (50 phút, nhiều thông tin hơn bài viết), cũng như đoạn trích chính từ nó ở dạng văn bản.
Lưu ý: Video và bản trình bày cũng có sẵn ở cuối bài này.
Giới thiệu
Thông thường một câu chuyện hay đều có phần mở đầu, cốt truyện chính và cách giải quyết. Báo cáo này giống như một khúc dạo đầu và một bi kịch hơn. Điều quan trọng cần lưu ý là nó cung cấp cái nhìn của người ngoài về microservice. khai thác.
Tôi sẽ bắt đầu với biểu đồ này, tác giả của nó (năm 2015) Martin Fowler:
Nó cho thấy, trong trường hợp một ứng dụng nguyên khối đạt đến một giá trị nhất định, năng suất bắt đầu giảm như thế nào. Microservice khác ở chỗ năng suất ban đầu của chúng thấp hơn, nhưng khi độ phức tạp tăng lên, sự suy giảm hiệu quả không quá đáng chú ý đối với chúng.
Tôi sẽ thêm vào biểu đồ này trong trường hợp sử dụng Kubernetes:
Tại sao ứng dụng có microservices lại tốt hơn? Bởi vì kiến trúc như vậy đặt ra các yêu cầu nghiêm túc cho kiến trúc, do đó kiến trúc này được đáp ứng một cách hoàn hảo bởi khả năng của Kubernetes. Mặt khác, một số chức năng này sẽ hữu ích cho một khối nguyên khối, đặc biệt vì khối nguyên khối điển hình ngày nay không hẳn là một khối nguyên khối (chi tiết sẽ có ở phần sau của báo cáo).
Như bạn có thể thấy, biểu đồ cuối cùng (khi cả ứng dụng nguyên khối và ứng dụng vi mô đều nằm trong cơ sở hạ tầng với Kubernetes) không khác lắm so với biểu đồ ban đầu. Tiếp theo chúng ta sẽ nói về các ứng dụng được vận hành bằng Kubernetes.
Vi dịch vụ hữu ích và có hại
Và đây là ý tưởng chính:
Điều gì là tất cả kiến trúc microservice? Nó sẽ mang lại cho bạn những lợi ích thiết thực, tăng hiệu quả công việc của bạn. Nếu chúng ta quay lại biểu đồ, đây là:
Nếu bạn gọi cô ấy hữu ích, thì ở phía bên kia của đồ thị sẽ có có hại microservices (can thiệp vào công việc):
Quay lại “ý chính”: tôi có nên tin tưởng vào trải nghiệm của mình không? Từ đầu năm nay tôi đã để ý 85 dự án. Không phải tất cả chúng đều là microservice (khoảng một phần ba đến một nửa trong số chúng có kiến trúc như vậy), nhưng đây vẫn là một con số lớn. Chúng tôi (công ty Flant) với tư cách là người đăng việc quản lý để thấy rất nhiều ứng dụng được phát triển ở cả các công ty nhỏ (với 5 nhà phát triển) và ở các công ty lớn (~500 nhà phát triển). Một lợi ích bổ sung là chúng tôi thấy các ứng dụng này tồn tại và phát triển qua nhiều năm.
Tại sao lại là microservice?
Đối với câu hỏi về lợi ích của microservices có từ Martin Fowler đã được đề cập:
- ranh giới rõ ràng của tính mô-đun;
- triển khai độc lập;
- tự do lựa chọn công nghệ.
Tôi đã nói chuyện rất nhiều với các kiến trúc sư và nhà phát triển phần mềm và hỏi tại sao họ cần microservice. Và tôi đã lập danh sách những mong đợi của họ. Đây là những gì đã xảy ra:
Nếu chúng ta mô tả một số điểm “trong cảm giác” thì:
- ranh giới rõ ràng của các mô-đun: ở đây chúng ta có một khối nguyên khối khủng khiếp, và bây giờ mọi thứ sẽ được sắp xếp gọn gàng trong kho Git, trong đó mọi thứ đều “trên kệ”, cái ấm và cái mềm không trộn lẫn với nhau;
- độc lập trong triển khai: chúng tôi sẽ có thể triển khai các dịch vụ một cách độc lập để quá trình phát triển diễn ra nhanh hơn (xuất bản song song các tính năng mới);
- tính độc lập trong phát triển: chúng tôi có thể cung cấp dịch vụ vi mô này cho một nhóm/nhà phát triển và dịch vụ đó cho nhóm khác, nhờ đó chúng tôi có thể phát triển nhanh hơn;
- боđộ tin cậy cao hơn: nếu xảy ra sự xuống cấp một phần (một dịch vụ vi mô trong số 20 lần rơi), thì chỉ một nút sẽ ngừng hoạt động và toàn bộ hệ thống sẽ tiếp tục hoạt động.
Kiến trúc microservice điển hình (có hại)
Để giải thích tại sao thực tế không như chúng ta mong đợi, tôi sẽ trình bày tập thể hình ảnh về kiến trúc microservice dựa trên kinh nghiệm từ nhiều dự án khác nhau.
Một ví dụ là một cửa hàng trực tuyến trừu tượng sắp cạnh tranh với Amazon hoặc ít nhất là OZON. Kiến trúc microservice của nó trông như thế này:
Vì nhiều lý do, các vi dịch vụ này được viết trên các nền tảng khác nhau:
Vì mỗi microservice phải có quyền tự chủ nên nhiều microservice trong số đó cần có cơ sở dữ liệu và bộ đệm riêng. Kiến trúc cuối cùng như sau:
Hậu quả của nó là gì?
Fowler cũng có cái này — về “khoản thanh toán” cho việc sử dụng vi dịch vụ:
Và chúng ta sẽ xem liệu kỳ vọng của chúng ta có được đáp ứng hay không.
Xóa ranh giới của các mô-đun...
Nhưng chúng ta thực sự cần sửa bao nhiêu microservice?để triển khai sự thay đổi? Liệu chúng ta có thể tìm ra cách mọi thứ hoạt động mà không cần đến trình theo dõi phân tán không (xét cho cùng, mọi yêu cầu đều được xử lý bởi một nửa số vi dịch vụ)?
Có một mẫu "“, và ở đây hóa ra đó là một cục đất rải rác. Để xác nhận điều này, đây là minh họa gần đúng về cách thực hiện các yêu cầu:
Triển khai độc lập...
Về mặt kỹ thuật, điều đó đã đạt được: chúng tôi có thể triển khai từng vi dịch vụ riêng biệt. Nhưng trong thực tế, bạn cần phải tính đến việc nó luôn xuất hiện nhiều microservice, và chúng ta cần tính đến thứ tự triển khai của họ. Nói chung, chúng tôi cần kiểm tra trong một mạch riêng xem liệu chúng tôi có tung ra bản phát hành theo đúng thứ tự hay không.
Tự do lựa chọn công nghệ...
Cô ấy là. Chỉ cần nhớ rằng tự do thường giáp với tình trạng vô luật pháp. Điều rất quan trọng ở đây là không nên chọn công nghệ chỉ để “chơi” với chúng.
Độc lập phát triển...
Làm cách nào để tạo vòng lặp thử nghiệm cho toàn bộ ứng dụng (với rất nhiều thành phần)? Nhưng bạn vẫn cần phải cập nhật nó. Tất cả điều này dẫn đến thực tế là số lượng mạch thử nghiệm thực tế, mà về nguyên tắc chúng ta có thể chứa, hóa ra là tối thiểu.
Và triển khai tất cả những thứ này cục bộ?.. Hóa ra là nhà phát triển thường thực hiện công việc của mình một cách độc lập, nhưng “ngẫu nhiên”, bởi vì anh ta buộc phải đợi cho đến khi mạch trống để thử nghiệm.
Tỉ lệ riêng biệt...
Có, nhưng nó bị giới hạn trong phạm vi DBMS được sử dụng. Trong ví dụ về kiến trúc đã cho, Cassandra sẽ không gặp vấn đề gì, nhưng MySQL và PostgreSQL thì có.
Боđộ tin cậy cao hơn...
Trên thực tế, sự cố của một microservice không chỉ thường làm gián đoạn hoạt động bình thường của toàn bộ hệ thống mà còn có một vấn đề mới: làm cho mọi microservice có khả năng chịu lỗi là rất khó. Bởi vì microservice sử dụng các công nghệ khác nhau (memcache, Redis, v.v.), nên đối với mỗi microservice, bạn cần phải suy nghĩ kỹ mọi thứ và triển khai nó, điều này tất nhiên là có thể thực hiện được nhưng đòi hỏi nguồn lực rất lớn.
Tải khả năng đo lường...
Cái này thật sự rất tốt.
Sự “nhẹ nhàng” của microservice...
Chúng tôi không chỉ có số lượng lớn chi phí mạng (các yêu cầu về DNS đang tăng lên, v.v.), nhưng cũng do có nhiều truy vấn phụ mà chúng tôi đã bắt đầu sao chép dữ liệu (lưu trữ bộ đệm), dẫn đến dung lượng lưu trữ đáng kể.
Và đây là kết quả đáp ứng được sự mong đợi của chúng tôi:
Nhưng đó không phải là tất cả!
Tại vì:
- Nhiều khả năng chúng ta sẽ cần một xe buýt nhắn tin.
- Làm thế nào để tạo một bản sao lưu nhất quán vào đúng thời điểm? Thứ duy nhất thực tế tùy chọn là tắt lưu lượng truy cập cho việc này. Nhưng làm thế nào để thực hiện điều này trong sản xuất?
- Nếu chúng ta đang nói về việc hỗ trợ một số khu vực, thì việc tổ chức tính bền vững ở mỗi khu vực đó là một nhiệm vụ rất tốn nhiều công sức.
- Vấn đề thực hiện các thay đổi tập trung phát sinh. Ví dụ: nếu chúng tôi cần cập nhật phiên bản PHP, chúng tôi sẽ cần phải cam kết với từng kho lưu trữ (và có hàng tá kho lưu trữ đó).
- Sự tăng trưởng về độ phức tạp trong hoạt động rõ ràng là theo cấp số nhân.
Phải làm gì với tất cả điều này?
Bắt đầu với một ứng dụng nguyên khối. kinh nghiệm của Fowler rằng hầu hết tất cả các ứng dụng microservice thành công đều bắt đầu dưới dạng nguyên khối, trở nên quá lớn và sau đó bị hỏng. Đồng thời, hầu hết tất cả các hệ thống được xây dựng dưới dạng microservice ngay từ đầu sớm hay muộn đều gặp phải sự cố nghiêm trọng.
Một suy nghĩ đáng giá khác là để một dự án có kiến trúc microservice thành công, bạn phải biết rất rõ và lĩnh vực chủ đề cũng như cách tạo ra các dịch vụ vi mô. Và cách tốt nhất để học một môn học là làm một khối nguyên khối.
Nhưng nếu chúng ta đã ở trong tình huống này thì sao?
Bước đầu tiên để giải quyết bất kỳ vấn đề nào là đồng ý với nó và hiểu rằng đó là một vấn đề, rằng chúng ta không muốn đau khổ nữa.
Nếu, trong trường hợp một khối nguyên khối phát triển quá mức (khi chúng ta không còn cơ hội mua thêm tài nguyên cho nó), chúng ta cắt nó, thì trong trường hợp này, câu chuyện ngược lại sẽ diễn ra: khi quá nhiều dịch vụ vi mô không còn giúp ích mà còn cản trở - cắt bỏ phần thừa và phóng to!
Ví dụ: đối với hình ảnh tập thể được thảo luận ở trên...
Loại bỏ các microservice đáng ngờ nhất:
Kết hợp tất cả các vi dịch vụ chịu trách nhiệm tạo giao diện người dùng:
... vào một microservice, được viết bằng một ngôn ngữ/khung (hiện đại và bình thường, như chính bạn nghĩ):
Nó sẽ có một ORM (một DBMS) và đầu tiên là một vài ứng dụng:
... nhưng nói chung bạn có thể chuyển nhiều hơn ở đó, nhận được kết quả như sau:
Hơn nữa, trong Kubernetes, chúng tôi chạy tất cả những thứ này trong các trường hợp riêng biệt, điều đó có nghĩa là chúng tôi vẫn có thể đo tải và chia tỷ lệ chúng một cách riêng biệt.
Tóm tắt
Nhìn vào bức tranh lớn hơn. Rất thường xuyên, tất cả những vấn đề này với microservice đều phát sinh do ai đó đã nhận nhiệm vụ của họ nhưng lại muốn “chơi với microservice”.
Trong từ “microservices” phần “micro” là dư thừa.. Chúng chỉ là “vi mô” vì chúng nhỏ hơn một tảng đá nguyên khối khổng lồ. Nhưng đừng coi chúng là điều gì đó nhỏ nhặt.
Và để suy nghĩ cuối cùng, hãy quay lại biểu đồ ban đầu:
Một ghi chú được viết trên đó (trên cùng bên phải) tóm lại thực tế là kỹ năng của nhóm khiến dự án của bạn luôn được ưu tiên hàng đầu — chúng sẽ đóng vai trò quan trọng trong việc bạn lựa chọn giữa dịch vụ vi mô và dịch vụ nguyên khối. Nếu nhóm không có đủ kỹ năng nhưng lại bắt đầu tạo ra các microservice, câu chuyện chắc chắn sẽ rất tai hại.
Video và slide
Video từ bài phát biểu (~ 50 phút; thật không may, nó không truyền tải được nhiều cảm xúc của khách tham quan, điều này quyết định phần lớn tâm trạng của báo cáo, nhưng thực tế là như vậy):
Trình bày báo cáo:
PS
Các báo cáo khác trên blog của chúng tôi:
- «» (Dmitry Stolyarov; ngày 28 tháng 2018 năm XNUMX tại RootConf);
- «» (Dmitry Stolyarov; ngày 7 tháng 2017 năm XNUMX trên HighLoad++);
- «» (Dmitry Stolyarov; ngày 6 tháng 2017 năm XNUMX tại RootConf);
- «» (Dmitry Stolyarov; ngày 8 tháng 2016 năm XNUMX trên HighLoad++);
- «» (Dmitry Stolyarov; ngày 31 tháng 2016 năm XNUMX tại RootConf).
Bạn cũng có thể quan tâm đến các ấn phẩm sau:
- «»;
- «»;
- «'.
Nguồn: www.habr.com