Bạn đã dành nhiều tháng để thiết kế lại khối nguyên khối của mình thành các vi dịch vụ và cuối cùng mọi người đã cùng nhau chuyển đổi. Bạn vào trang web đầu tiên... và không có gì xảy ra. Bạn tải lại - và một lần nữa không có gì tốt, trang web chậm đến mức không phản hồi trong vài phút. Chuyện gì đã xảy ra thế?
Trong bài nói chuyện của mình, Jimmy Bogard sẽ tiến hành “khám nghiệm tử thi” về một thảm họa microservice trong đời thực. Anh ấy sẽ trình bày các vấn đề về mô hình hóa, phát triển và sản xuất mà anh ấy đã khám phá cũng như cách nhóm của anh ấy dần dần biến khối nguyên khối được phân phối mới thành bức tranh cuối cùng về sự tỉnh táo. Mặc dù không thể ngăn chặn hoàn toàn các lỗi thiết kế nhưng ít nhất bạn có thể xác định sớm các vấn đề trong quá trình thiết kế để đảm bảo sản phẩm cuối cùng trở thành một hệ thống phân phối đáng tin cậy.
Xin chào mọi người, tôi là Jimmy và hôm nay các bạn sẽ nghe cách có thể tránh những thảm họa lớn khi xây dựng vi dịch vụ. Đây là câu chuyện về một công ty mà tôi đã làm việc khoảng một năm rưỡi để giúp ngăn con tàu của họ va chạm với một tảng băng trôi. Để kể câu chuyện này một cách chính xác, chúng ta sẽ phải quay ngược thời gian và nói về nơi công ty này bắt đầu và cơ sở hạ tầng CNTT của nó đã phát triển như thế nào theo thời gian. Để bảo vệ tên tuổi của những người vô tội trong thảm họa này, tôi đã đổi tên công ty này thành Bell Computers. Trang trình bày tiếp theo cho thấy cơ sở hạ tầng CNTT của các công ty như vậy trông như thế nào vào giữa những năm 90. Đây là kiến trúc điển hình của máy chủ HP Tandem Mainframe có khả năng chịu lỗi phổ quát lớn để vận hành một cửa hàng phần cứng máy tính.
Họ cần xây dựng một hệ thống để quản lý tất cả các đơn đặt hàng, doanh số bán hàng, hàng trả lại, danh mục sản phẩm và cơ sở khách hàng, vì vậy họ đã chọn giải pháp máy tính lớn phổ biến nhất vào thời điểm đó. Hệ thống khổng lồ này chứa đựng mọi thông tin nhỏ nhất về công ty, mọi thứ có thể có, và mọi giao dịch đều được thực hiện thông qua máy tính lớn này. Họ bỏ tất cả trứng vào một giỏ và cho rằng đó là chuyện bình thường. Điều duy nhất không được đưa vào đây là danh mục đặt hàng qua thư và đặt hàng qua điện thoại.
Theo thời gian, hệ thống ngày càng lớn hơn và một lượng rác khổng lồ tích tụ trong đó. Ngoài ra, COBOL không phải là ngôn ngữ biểu cảm nhất trên thế giới, vì vậy hệ thống này cuối cùng trở thành một mảnh rác nguyên khối lớn. Đến năm 2000, họ nhận thấy nhiều công ty có trang web để thực hiện mọi hoạt động kinh doanh của mình và quyết định xây dựng trang web dot-com thương mại đầu tiên của mình.
Thiết kế ban đầu trông khá đẹp và bao gồm một trang web cấp cao nhất bell.com và một số tên miền phụ cho các ứng dụng riêng lẻ: catalog.bell.com, Accounts.bell.com, order.bell.com, tìm kiếm sản phẩm search.bell. com. Mỗi tên miền phụ sử dụng khung ASP.Net 1.0 và cơ sở dữ liệu riêng của nó, đồng thời tất cả đều giao tiếp với phần phụ trợ của hệ thống. Tuy nhiên, tất cả các đơn đặt hàng vẫn tiếp tục được xử lý và thực thi trong một máy tính lớn duy nhất, trong đó tất cả rác vẫn còn, nhưng giao diện người dùng là các trang web riêng biệt với các ứng dụng riêng lẻ và cơ sở dữ liệu riêng biệt.
Vì vậy, thiết kế của hệ thống trông có trật tự và hợp lý, nhưng hệ thống thực tế lại như được trình bày trong slide tiếp theo.
Tất cả các phần tử đều giải quyết các cuộc gọi với nhau, các API được truy cập, các dll được nhúng của bên thứ ba và những thứ tương tự. Điều thường xảy ra là các hệ thống kiểm soát phiên bản sẽ lấy mã của người khác, nhét nó vào trong dự án và sau đó mọi thứ sẽ hỏng. MS SQL Server 2005 đã sử dụng khái niệm máy chủ liên kết và mặc dù tôi không hiển thị các mũi tên trên trang chiếu nhưng mỗi cơ sở dữ liệu cũng liên lạc với nhau, vì không có gì sai khi xây dựng bảng dựa trên dữ liệu thu được từ một số cơ sở dữ liệu.
Vì giờ đây họ đã có sự tách biệt giữa các khu vực logic khác nhau của hệ thống nên điều này đã trở thành những khối rác được phân phối, với phần rác lớn nhất vẫn còn sót lại trong phần phụ trợ của máy tính lớn.
Điều buồn cười là chiếc máy tính lớn này được các đối thủ cạnh tranh của Bell Computers chế tạo và vẫn được các chuyên gia tư vấn kỹ thuật của họ bảo trì. Bị thuyết phục bởi hiệu suất không đạt yêu cầu của các ứng dụng, công ty quyết định loại bỏ chúng và thiết kế lại hệ thống.
Ứng dụng hiện tại đã được sản xuất được 15 năm, đây là một kỷ lục đối với các ứng dụng dựa trên ASP.Net. Dịch vụ này đã nhận đơn đặt hàng từ khắp nơi trên thế giới và doanh thu hàng năm từ ứng dụng này đã đạt tới một tỷ đô la. Một phần lợi nhuận đáng kể được tạo ra bởi trang web bell.com. Vào ngày Thứ Sáu Đen, số lượng đơn đặt hàng qua trang này lên tới vài triệu. Tuy nhiên, kiến trúc hiện tại không cho phép bất kỳ sự phát triển nào, vì thực tế các mối liên kết chặt chẽ của các thành phần hệ thống không cho phép thực hiện bất kỳ thay đổi nào đối với dịch vụ.
Vấn đề nghiêm trọng nhất là không thể đặt hàng từ một quốc gia, thanh toán ở quốc gia khác và gửi đến quốc gia thứ ba, mặc dù thực tế là kế hoạch giao dịch như vậy rất phổ biến ở các công ty toàn cầu. Trang web hiện tại không cho phép bất cứ điều gì như thế này, vì vậy họ phải chấp nhận và đặt hàng qua điện thoại. Điều này khiến công ty ngày càng nghĩ đến việc thay đổi kiến trúc, đặc biệt là chuyển sang microservices.
Họ đã làm một điều thông minh bằng cách quan sát các công ty khác để xem họ đã giải quyết vấn đề tương tự như thế nào. Một trong những giải pháp này là kiến trúc dịch vụ Netflix, bao gồm các dịch vụ vi mô được kết nối thông qua API và cơ sở dữ liệu bên ngoài.
Ban quản lý Bell Computers quyết định xây dựng một kiến trúc như vậy, tuân thủ các nguyên tắc cơ bản nhất định. Đầu tiên, họ loại bỏ sự trùng lặp dữ liệu bằng cách sử dụng phương pháp cơ sở dữ liệu dùng chung. Không có dữ liệu nào được gửi đi, ngược lại, tất cả những ai cần nó đều phải đến một nguồn tập trung. Tiếp theo đó là sự cô lập và tự chủ - mỗi dịch vụ đều độc lập với các dịch vụ khác. Họ quyết định sử dụng API Web cho mọi thứ - nếu bạn muốn lấy dữ liệu hoặc thực hiện các thay đổi đối với hệ thống khác, tất cả đều được thực hiện thông qua API Web. Điều quan trọng cuối cùng là một máy tính lớn mới có tên "Bell on Bell" trái ngược với máy tính lớn "Bell" dựa trên phần cứng của đối thủ cạnh tranh.
Vì vậy, trong suốt 18 tháng, họ đã xây dựng hệ thống dựa trên những nguyên tắc cốt lõi này và đưa nó vào giai đoạn tiền sản xuất. Trở lại làm việc sau cuối tuần, các nhà phát triển đã cùng nhau bật tất cả các máy chủ mà hệ thống mới được kết nối. 18 tháng làm việc, hàng trăm nhà phát triển, phần cứng Bell hiện đại nhất - và không có kết quả khả quan nào! Điều này đã làm nhiều người thất vọng vì họ đã chạy hệ thống này trên máy tính xách tay của mình nhiều lần và mọi thứ đều ổn.
Họ thật thông minh khi ném hết tiền của mình vào việc giải quyết vấn đề này. Họ đã lắp đặt các giá đỡ máy chủ hiện đại nhất có bộ chuyển mạch, sử dụng cáp quang gigabit, phần cứng máy chủ mạnh nhất với dung lượng RAM khủng khiếp, kết nối tất cả, cấu hình nó - và một lần nữa, không có gì cả! Sau đó, họ bắt đầu nghi ngờ rằng lý do có thể là do thời gian chờ, vì vậy họ đã đi vào tất cả cài đặt web, tất cả cài đặt API và cập nhật toàn bộ cấu hình thời gian chờ lên giá trị tối đa, để tất cả những gì họ có thể làm là ngồi chờ điều gì đó xảy ra. vào trang web. Họ đợi và chờ suốt 9 phút rưỡi cho đến khi trang web được tải xong.
Sau đó, họ nhận ra rằng tình hình hiện tại cần được phân tích kỹ lưỡng và họ đã mời chúng tôi. Điều đầu tiên chúng tôi phát hiện ra là trong suốt 18 tháng phát triển, không một “vi mô” thực sự nào được tạo ra - mọi thứ chỉ ngày càng lớn hơn. Sau đó, chúng tôi bắt đầu viết một bản khám nghiệm tử thi hay còn gọi là “hối hận”, hay “hồi tưởng buồn”, hay còn gọi là “cơn bão đổ lỗi”, tương tự như “cơn bão não”, để hiểu nguyên nhân của thảm họa.
Chúng tôi đã có một số manh mối, một trong số đó là tình trạng bão hòa lưu lượng truy cập hoàn toàn tại thời điểm gọi API. Khi sử dụng kiến trúc dịch vụ nguyên khối, bạn có thể hiểu ngay chính xác điều gì đã xảy ra vì bạn có một dấu vết ngăn xếp duy nhất báo cáo mọi thứ có thể gây ra lỗi. Trong trường hợp một loạt dịch vụ truy cập đồng thời vào cùng một API, không có cách nào để theo dõi dấu vết ngoại trừ việc sử dụng các công cụ giám sát mạng bổ sung như WireShark, nhờ đó bạn có thể kiểm tra một yêu cầu duy nhất và tìm hiểu điều gì đã xảy ra trong quá trình triển khai. Vì vậy, chúng tôi đã lấy một trang web và dành gần 2 tuần để ghép các mảnh ghép lại với nhau, thực hiện nhiều cách gọi khác nhau và phân tích xem mỗi mảnh ghép đó dẫn đến điều gì.
Nhìn vào bức tranh này. Nó cho thấy rằng một yêu cầu bên ngoài sẽ nhắc dịch vụ thực hiện nhiều lệnh gọi nội bộ quay trở lại. Hóa ra mỗi cuộc gọi nội bộ sẽ thực hiện các bước nhảy bổ sung để có thể phục vụ yêu cầu này một cách độc lập, bởi vì nó không thể quay đi nơi khác để có được thông tin cần thiết. Hình ảnh này trông giống như một chuỗi các cuộc gọi vô nghĩa, vì yêu cầu bên ngoài gọi các dịch vụ bổ sung, gọi các dịch vụ bổ sung khác, v.v., gần như vô tận.
Màu xanh lục trong sơ đồ này hiển thị hình bán nguyệt trong đó các dịch vụ gọi nhau - dịch vụ A gọi dịch vụ B, dịch vụ B gọi dịch vụ C và nó gọi lại dịch vụ A. Kết quả là chúng ta nhận được “bế tắc phân tán”. Một yêu cầu duy nhất đã tạo ra hàng nghìn lệnh gọi API mạng và do hệ thống không có khả năng chịu lỗi và bảo vệ vòng lặp tích hợp nên yêu cầu sẽ không thành công nếu ngay cả một trong các lệnh gọi API này không thành công.
Chúng tôi đã làm một số phép toán. Mỗi lệnh gọi API có SLA không quá 150 mili giây và thời gian hoạt động là 99,9%. Một yêu cầu gây ra 200 cuộc gọi khác nhau và trong trường hợp tốt nhất, trang có thể được hiển thị trong 200 x 150 mili giây = 30 giây. Đương nhiên, điều này là không tốt. Nhân 99,9% thời gian hoạt động với 200, chúng ta có 0% khả dụng. Hóa ra kiến trúc này ngay từ đầu đã thất bại.
Chúng tôi đã hỏi các nhà phát triển tại sao họ không nhận ra vấn đề này sau 18 tháng làm việc? Hóa ra họ chỉ tính SLA cho mã họ chạy, còn nếu dịch vụ của họ gọi dịch vụ khác thì họ không tính thời gian đó vào SLA của mình. Mọi thứ được khởi chạy trong một quy trình đều tuân theo giá trị 150 ms, nhưng quyền truy cập vào các quy trình dịch vụ khác đã làm tăng tổng độ trễ lên nhiều lần. Bài học đầu tiên rút ra là: “Bạn đang kiểm soát SLA của mình hay SLA đang kiểm soát bạn?” Trong trường hợp của chúng tôi, đó là cái sau.
Điều tiếp theo mà chúng tôi phát hiện ra là họ biết về những quan niệm sai lầm về điện toán phân tán do Peter Deitch và James Gosling đưa ra, nhưng họ đã bỏ qua phần đầu tiên của nó. Nó tuyên bố rằng các tuyên bố “mạng đáng tin cậy”, “độ trễ bằng XNUMX” và “thông lượng vô hạn” là những quan niệm sai lầm. Những quan niệm sai lầm khác bao gồm các tuyên bố “mạng an toàn”, “cấu trúc liên kết không bao giờ thay đổi”, “luôn chỉ có một quản trị viên”, “chi phí truyền dữ liệu bằng XNUMX” và “mạng đồng nhất”.
Họ đã phạm sai lầm vì đã thử nghiệm dịch vụ của mình trên các máy cục bộ và không bao giờ kết nối với các dịch vụ bên ngoài. Khi phát triển cục bộ và sử dụng bộ nhớ đệm cục bộ, họ không bao giờ gặp phải tình trạng nhảy mạng. Trong suốt 18 tháng phát triển, họ chưa một lần tự hỏi điều gì sẽ xảy ra nếu dịch vụ bên ngoài bị ảnh hưởng.
Nếu bạn nhìn vào ranh giới dịch vụ trong hình trước, bạn có thể thấy rằng tất cả chúng đều không chính xác. Có rất nhiều nguồn tư vấn về cách xác định ranh giới dịch vụ và hầu hết đều làm sai, như Microsoft ở slide tiếp theo.
Bức ảnh này lấy từ blog MS về chủ đề “Cách xây dựng microservices”. Phần này hiển thị một ứng dụng web đơn giản, một khối logic nghiệp vụ và cơ sở dữ liệu. Yêu cầu được gửi trực tiếp, có thể có một máy chủ dành cho web, một máy chủ dành cho doanh nghiệp và một máy chủ dành cho cơ sở dữ liệu. Nếu bạn tăng lưu lượng truy cập, hình ảnh sẽ thay đổi một chút.
Ở đây có bộ cân bằng tải để phân phối lưu lượng giữa hai máy chủ web, bộ đệm nằm giữa dịch vụ web và logic nghiệp vụ và một bộ đệm khác giữa logic nghiệp vụ và cơ sở dữ liệu. Đây chính xác là kiến trúc mà Bell đã sử dụng cho ứng dụng cân bằng tải và triển khai xanh/xanh vào giữa những năm 2000. Cho đến một thời điểm, mọi thứ đều hoạt động tốt, vì sơ đồ này được thiết kế cho một cấu trúc nguyên khối.
Hình ảnh sau đây cho thấy cách MS khuyến nghị chuyển từ nguyên khối sang vi dịch vụ - chỉ cần chia từng dịch vụ chính thành các vi dịch vụ riêng biệt. Chính trong quá trình thực hiện kế hoạch này, Bell đã mắc sai lầm.
Họ chia tất cả các dịch vụ của mình thành các cấp khác nhau, mỗi cấp bao gồm nhiều dịch vụ riêng lẻ. Ví dụ: dịch vụ web bao gồm các microservice để hiển thị và xác thực nội dung, dịch vụ logic nghiệp vụ bao gồm các microservice để xử lý đơn đặt hàng và thông tin tài khoản, cơ sở dữ liệu được chia thành một loạt các microservice với dữ liệu chuyên biệt. Cả web, logic nghiệp vụ và cơ sở dữ liệu đều là các dịch vụ không trạng thái.
Tuy nhiên, bức tranh này hoàn toàn sai lầm vì nó không ánh xạ bất kỳ đơn vị kinh doanh nào ngoài cụm CNTT của công ty. Kế hoạch này không tính đến bất kỳ kết nối nào với thế giới bên ngoài, vì vậy không rõ làm cách nào để có được phân tích kinh doanh của bên thứ ba. Tôi lưu ý rằng họ cũng đã phát minh ra một số dịch vụ chỉ nhằm phát triển sự nghiệp của từng nhân viên, những người tìm cách quản lý càng nhiều người càng tốt để kiếm được nhiều tiền hơn cho công việc đó.
Họ tin rằng việc chuyển sang microservice cũng dễ dàng như sử dụng cơ sở hạ tầng lớp vật lý cấp N nội bộ của họ và gắn Docker vào đó. Chúng ta hãy xem kiến trúc N-tier truyền thống trông như thế nào.
Nó bao gồm 4 cấp độ: cấp độ giao diện người dùng UI, cấp độ logic nghiệp vụ, cấp độ truy cập dữ liệu và cơ sở dữ liệu. Tiến bộ hơn là DDD (Thiết kế hướng tên miền) hoặc kiến trúc hướng phần mềm, trong đó hai cấp độ trung gian là đối tượng miền và kho lưu trữ.
Tôi đã cố gắng xem xét các lĩnh vực thay đổi khác nhau, các lĩnh vực trách nhiệm khác nhau trong kiến trúc này. Trong một ứng dụng N-tier điển hình, các vùng thay đổi khác nhau được phân loại xuyên suốt cấu trúc theo chiều dọc từ trên xuống dưới. Đây là các cài đặt Danh mục, Cấu hình được thực hiện trên từng máy tính và kiểm tra Checkout do nhóm của tôi xử lý.
Điểm đặc biệt của sơ đồ này là ranh giới của các lĩnh vực thay đổi này không chỉ ảnh hưởng đến mức logic nghiệp vụ mà còn mở rộng đến cơ sở dữ liệu.
Chúng ta hãy xem ý nghĩa của việc trở thành một dịch vụ là gì. Có 6 thuộc tính đặc trưng của định nghĩa dịch vụ - đó là phần mềm:
- được tạo ra và sử dụng bởi một tổ chức cụ thể;
- chịu trách nhiệm về nội dung, xử lý và/hoặc cung cấp một loại thông tin nhất định trong hệ thống;
- có thể được xây dựng, triển khai và vận hành độc lập nhằm đáp ứng các nhu cầu vận hành cụ thể;
- giao tiếp với người tiêu dùng và các dịch vụ khác, cung cấp thông tin dựa trên các thỏa thuận hoặc đảm bảo trong hợp đồng;
- bảo vệ bản thân khỏi sự truy cập trái phép và thông tin của nó khỏi bị mất;
- xử lý các lỗi theo cách mà chúng không dẫn đến thiệt hại thông tin.
Tất cả những đặc tính này có thể được diễn đạt bằng một từ “tự chủ”. Các dịch vụ hoạt động độc lập với nhau, đáp ứng một số hạn chế nhất định và xác định hợp đồng trên cơ sở đó mọi người có thể nhận được thông tin họ cần. Tôi đã không đề cập đến các công nghệ cụ thể, việc sử dụng chúng là hiển nhiên.
Bây giờ hãy xem định nghĩa của microservice:
- microservice có kích thước nhỏ và được thiết kế để giải quyết một vấn đề cụ thể;
- Microservice có tính tự chủ;
- Khi tạo kiến trúc microservice, phép ẩn dụ quy hoạch thị trấn được sử dụng. Đây là định nghĩa từ cuốn sách Xây dựng vi dịch vụ của Sam Newman.
Định nghĩa về Bối cảnh bị ràng buộc được lấy từ cuốn sách Thiết kế hướng tên miền của Eric Evans. Đây là mẫu cốt lõi trong DDD, một trung tâm thiết kế kiến trúc làm việc với các mô hình kiến trúc thể tích, chia chúng thành các Bối cảnh giới hạn khác nhau và xác định rõ ràng các tương tác giữa chúng.
Nói một cách đơn giản, Bối cảnh bị ràng buộc biểu thị phạm vi mà một mô-đun cụ thể có thể được sử dụng. Trong bối cảnh này là một mô hình thống nhất về mặt logic mà bạn có thể thấy, chẳng hạn như trong lĩnh vực kinh doanh của bạn. Nếu bạn hỏi “khách hàng là ai” với những người tham gia đặt hàng, bạn sẽ nhận được một định nghĩa, nếu bạn hỏi những người tham gia bán hàng, bạn sẽ nhận được một định nghĩa khác, và những người thực hiện sẽ cho bạn định nghĩa thứ ba.
Vì vậy, Bối cảnh bị ràng buộc nói rằng nếu chúng ta không thể đưa ra định nghĩa rõ ràng về người tiêu dùng dịch vụ của mình là gì, hãy xác định các ranh giới mà chúng ta có thể nói về ý nghĩa của thuật ngữ này và sau đó xác định các điểm chuyển tiếp giữa các định nghĩa khác nhau này. Nghĩa là, nếu chúng ta đang nói về một khách hàng từ quan điểm đặt hàng, thì điều này có nghĩa là thế này và thế kia, và nếu từ quan điểm bán hàng, thì điều này có nghĩa là thế này và thế kia.
Định nghĩa tiếp theo của microservice là sự đóng gói của bất kỳ loại hoạt động nội bộ nào, ngăn chặn sự “rò rỉ” của các thành phần của quy trình làm việc ra môi trường. Tiếp theo là “định nghĩa về hợp đồng rõ ràng cho các tương tác bên ngoài hoặc liên lạc bên ngoài”, được thể hiện bằng ý tưởng về các hợp đồng trả về từ SLA. Định nghĩa cuối cùng là phép ẩn dụ của một ô hoặc ô, có nghĩa là sự đóng gói hoàn chỉnh của một tập hợp các hoạt động trong một vi dịch vụ và sự hiện diện trong đó của các thụ thể để giao tiếp với thế giới bên ngoài.
Vì vậy, chúng tôi đã nói với những người ở Bell Computers: “Chúng tôi không thể khắc phục bất kỳ sự hỗn loạn nào mà các bạn đã tạo ra bởi vì các bạn không có tiền để làm việc đó, nhưng chúng tôi sẽ chỉ khắc phục một dịch vụ để biến tất cả thành công”. giác quan." Tại thời điểm này, tôi sẽ bắt đầu bằng cách cho bạn biết cách chúng tôi khắc phục dịch vụ duy nhất của mình để nó phản hồi các yêu cầu nhanh hơn 9 phút rưỡi.
22:30 phút
Sẽ sớm được tiếp tục...
Một chút quảng cáo
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com