Chào mọi người! Chúng tôi có tin vui, OTUS sẽ khai giảng lại khóa học vào tháng 6 , liên quan đến việc chúng tôi thường chia sẻ tài liệu hữu ích với bạn.
Nếu bạn đã xem toàn bộ dịch vụ vi mô này mà không có bất kỳ ngữ cảnh nào, bạn sẽ được tha thứ vì nghĩ rằng nó hơi lạ. Việc chia ứng dụng thành các phần được kết nối bằng mạng nhất thiết có nghĩa là thêm các chế độ chịu lỗi phức tạp vào hệ thống phân tán thu được.
Mặc dù cách tiếp cận này liên quan đến việc chia nhỏ nó thành nhiều dịch vụ độc lập nhưng mục tiêu cuối cùng không chỉ là để các dịch vụ đó chạy trên các máy khác nhau. Ở đây chúng ta đang nói về sự tương tác với thế giới bên ngoài, bản chất của nó cũng được phân bổ. Không phải theo nghĩa kỹ thuật, mà là theo nghĩa một hệ sinh thái bao gồm nhiều người, nhóm, chương trình và mỗi bộ phận này bằng cách nào đó cần phải thực hiện công việc của mình.
Ví dụ, các công ty là một tập hợp các hệ thống phân tán cùng đóng góp vào việc đạt được một số mục tiêu. Chúng ta đã bỏ qua thực tế này trong nhiều thập kỷ, cố gắng đạt được sự thống nhất bằng cách gửi các tệp FTP hoặc sử dụng các công cụ tích hợp doanh nghiệp trong khi tập trung vào các mục tiêu riêng biệt của riêng mình. Nhưng với sự ra đời của dịch vụ, mọi thứ đã thay đổi. Các dịch vụ đã giúp chúng tôi nhìn xa hơn và nhìn thấy một thế giới gồm các chương trình phụ thuộc lẫn nhau hoạt động cùng nhau. Tuy nhiên, để hoạt động thành công, cần phải nhận ra và thiết kế hai thế giới cơ bản khác nhau: thế giới bên ngoài, nơi chúng ta sống trong một hệ sinh thái gồm nhiều dịch vụ khác, và thế giới nội tâm, cá nhân của chúng ta, nơi chúng ta cai trị một mình.
Thế giới phân tán này khác với thế giới mà chúng ta đã lớn lên và quen thuộc. Các nguyên tắc xây dựng kiến trúc nguyên khối truyền thống không đứng vững trước những lời chỉ trích. Vì vậy, việc sử dụng đúng các hệ thống này không chỉ đơn thuần là tạo ra một sơ đồ bảng trắng hay một bằng chứng thú vị về khái niệm. Vấn đề là đảm bảo rằng một hệ thống như vậy hoạt động thành công trong một thời gian dài. May mắn thay, các dịch vụ này đã xuất hiện được một thời gian, mặc dù chúng trông có vẻ khác nhau. vẫn có liên quan, thậm chí dày dạn với Docker, Kubernetes và bộ râu hipster hơi tồi tàn.
Vì vậy, hôm nay chúng ta sẽ xem xét các quy tắc đã thay đổi như thế nào, tại sao chúng ta cần suy nghĩ lại cách chúng ta tiếp cận các dịch vụ và dữ liệu chúng truyền cho nhau và tại sao chúng ta lại cần những công cụ hoàn toàn khác nhau để thực hiện điều đó.
Đóng gói sẽ không phải lúc nào cũng là bạn của bạn
Các microservice có thể hoạt động độc lập với nhau. Chính tài sản này mang lại cho họ giá trị lớn nhất. Thuộc tính tương tự này cho phép các dịch vụ mở rộng quy mô và phát triển. Không phải theo nghĩa mở rộng quy mô tới hàng triệu triệu người dùng hoặc petabyte dữ liệu (mặc dù những điều đó cũng có thể trợ giúp ở đó), mà theo nghĩa mở rộng quy mô về mặt con người khi các nhóm và tổ chức phát triển liên tục.
Tuy nhiên, độc lập là con dao hai lưỡi. Nghĩa là, bản thân dịch vụ có thể chạy dễ dàng và tự nhiên. Nhưng nếu một chức năng được triển khai trong một dịch vụ yêu cầu sử dụng dịch vụ khác thì cuối cùng chúng ta phải thực hiện các thay đổi đối với cả hai dịch vụ gần như đồng thời. Trong nguyên khối, điều này rất dễ thực hiện, bạn chỉ cần thực hiện thay đổi và gửi nó để phát hành, nhưng trong trường hợp đồng bộ hóa các dịch vụ độc lập sẽ có nhiều vấn đề hơn. Sự phối hợp giữa các nhóm và chu kỳ phát hành sẽ phá hủy sự linh hoạt.
Là một phần của cách tiếp cận tiêu chuẩn, họ chỉ cần cố gắng tránh những thay đổi gây phiền nhiễu từ đầu đến cuối, phân chia rõ ràng chức năng giữa các dịch vụ. Dịch vụ đăng nhập một lần có thể là một ví dụ điển hình ở đây. Nó có một vai trò được xác định rõ ràng để phân biệt nó với các dịch vụ khác. Sự tách biệt rõ ràng này có nghĩa là trong một thế giới có nhu cầu thay đổi nhanh chóng đối với các dịch vụ xung quanh, dịch vụ đăng nhập một lần khó có thể thay đổi. Nó tồn tại trong một bối cảnh hạn chế nghiêm ngặt.
Vấn đề là trong thế giới thực, các dịch vụ kinh doanh không thể luôn duy trì sự phân tách vai trò thuần túy như nhau. Ví dụ: các dịch vụ kinh doanh tương tự hoạt động ở mức độ lớn hơn với dữ liệu đến từ các dịch vụ tương tự khác. Nếu bạn tham gia bán lẻ trực tuyến thì việc xử lý luồng đơn hàng, danh mục sản phẩm hoặc thông tin người dùng sẽ trở thành yêu cầu đối với nhiều dịch vụ của bạn. Mỗi dịch vụ sẽ cần quyền truy cập vào dữ liệu này để hoạt động.
Hầu hết các dịch vụ kinh doanh đều chia sẻ cùng một luồng dữ liệu, vì vậy công việc của chúng luôn gắn liền với nhau.
Như vậy chúng ta đã đi đến một điểm quan trọng đáng nói đến. Mặc dù các dịch vụ hoạt động tốt đối với các thành phần cơ sở hạ tầng hoạt động chủ yếu một cách biệt lập, nhưng hầu hết các dịch vụ kinh doanh cuối cùng lại được kết hợp chặt chẽ hơn nhiều.
Sự phân đôi dữ liệu
Các phương pháp tiếp cận hướng dịch vụ có thể đã tồn tại nhưng chúng vẫn thiếu hiểu biết sâu sắc về cách chia sẻ lượng lớn dữ liệu giữa các dịch vụ.
Vấn đề chính là dữ liệu và dịch vụ không thể tách rời. Một mặt, việc đóng gói khuyến khích chúng ta ẩn dữ liệu để các dịch vụ có thể tách biệt với nhau và tạo điều kiện cho chúng phát triển cũng như những thay đổi tiếp theo. Mặt khác, chúng ta cần có khả năng tự do phân chia và chinh phục dữ liệu được chia sẻ, giống như bất kỳ dữ liệu nào khác. Vấn đề là có thể bắt đầu làm việc ngay lập tức, một cách tự do như trong bất kỳ hệ thống thông tin nào khác.
Tuy nhiên, hệ thống thông tin ít liên quan đến việc đóng gói. Trên thực tế, nó hoàn toàn ngược lại. Cơ sở dữ liệu làm mọi thứ có thể để cung cấp quyền truy cập vào dữ liệu họ lưu trữ. Chúng đi kèm với một giao diện khai báo mạnh mẽ cho phép bạn sửa đổi dữ liệu khi cần. Chức năng như vậy rất quan trọng ở giai đoạn nghiên cứu sơ bộ, nhưng không phải để quản lý mức độ phức tạp ngày càng tăng của một dịch vụ không ngừng phát triển.
Và ở đây nảy sinh một vấn đề nan giải. Sự mâu thuẫn. Sự phân đôi. Suy cho cùng, hệ thống thông tin là nơi cung cấp dữ liệu, còn dịch vụ là nơi ẩn náu.
Hai lực này là cơ bản. Chúng củng cố phần lớn công việc của chúng tôi, không ngừng đấu tranh để đạt được sự xuất sắc trong hệ thống mà chúng tôi xây dựng.
Khi các hệ thống dịch vụ phát triển và phát triển, chúng ta thấy hậu quả của sự phân đôi dữ liệu theo nhiều cách. Giao diện dịch vụ sẽ phát triển, cung cấp phạm vi chức năng ngày càng tăng và bắt đầu trông giống như một cơ sở dữ liệu cây nhà lá vườn rất lạ mắt, hoặc chúng ta sẽ trở nên thất vọng và triển khai một số cách để truy xuất hoặc di chuyển toàn bộ bộ dữ liệu từ dịch vụ này sang dịch vụ khác.
Đổi lại, việc tạo ra thứ gì đó trông giống như một cơ sở dữ liệu cây nhà lá vườn sang trọng sẽ dẫn đến một loạt vấn đề. Chúng tôi sẽ không đi vào chi tiết về lý do tại sao nó nguy hiểm cơ sở dữ liệu được chia sẻ, hãy chỉ nói rằng nó đại diện cho kỹ thuật và vận hành tốn kém đáng kể cho công ty đang cố gắng sử dụng nó.
Điều tệ hơn là khối lượng dữ liệu làm tăng thêm các vấn đề về ranh giới dịch vụ. Càng nhiều dữ liệu được chia sẻ trong một dịch vụ thì giao diện sẽ càng phức tạp và việc kết hợp các tập dữ liệu đến từ các dịch vụ khác nhau sẽ càng khó khăn hơn.
Cách tiếp cận khác là trích xuất và di chuyển toàn bộ tập dữ liệu cũng có vấn đề. Cách tiếp cận phổ biến cho câu hỏi này giống như chỉ cần truy xuất và lưu trữ toàn bộ tập dữ liệu, sau đó lưu trữ cục bộ trong mỗi dịch vụ tiêu dùng.
Vấn đề là các dịch vụ khác nhau diễn giải dữ liệu mà chúng sử dụng một cách khác nhau. Dữ liệu này luôn ở trong tầm tay. Chúng được sửa đổi và xử lý cục bộ. Rất nhanh chóng, chúng không còn điểm chung nào với dữ liệu trong nguồn.
Các bản sao càng có nhiều thay đổi thì dữ liệu sẽ càng thay đổi theo thời gian.
Tệ hơn nữa, dữ liệu đó rất khó sửa khi nhìn lại ( Đây là nơi nó thực sự có thể đến giải cứu). Trên thực tế, một số vấn đề công nghệ khó giải quyết mà doanh nghiệp gặp phải phát sinh từ dữ liệu khác nhau nhân lên từ ứng dụng này sang ứng dụng khác.
Để tìm giải pháp cho vấn đề này, chúng ta cần nghĩ khác về dữ liệu được chia sẻ. Chúng phải trở thành đối tượng hạng nhất trong kiến trúc mà chúng ta xây dựng. gọi dữ liệu đó là “bên ngoài” và đây là một tính năng rất quan trọng. Chúng tôi cần đóng gói để không tiết lộ hoạt động bên trong của dịch vụ, nhưng chúng tôi cần giúp các dịch vụ dễ dàng truy cập dữ liệu được chia sẻ để chúng có thể thực hiện công việc của mình một cách chính xác.
Vấn đề là ngày nay cả hai cách tiếp cận đều không phù hợp vì cả giao diện dịch vụ, nhắn tin cũng như Cơ sở dữ liệu dùng chung đều không cung cấp giải pháp tốt để làm việc với dữ liệu bên ngoài. Giao diện dịch vụ kém phù hợp để trao đổi dữ liệu ở mọi quy mô. Tin nhắn di chuyển dữ liệu nhưng không lưu trữ lịch sử của nó, do đó dữ liệu sẽ bị hỏng theo thời gian. Cơ sở dữ liệu dùng chung tập trung quá nhiều vào một điểm, điều này cản trở tiến độ. Chúng ta chắc chắn sẽ bị mắc kẹt trong một chu kỳ lỗi dữ liệu:
Chu kỳ lỗi dữ liệu
Luồng: cách tiếp cận phi tập trung đối với dữ liệu và dịch vụ
Lý tưởng nhất là chúng ta cần thay đổi cách các dịch vụ hoạt động với dữ liệu được chia sẻ. Tại thời điểm này, cả hai cách tiếp cận đều phải đối mặt với sự phân đôi đã nói ở trên, vì không có loại bụi ma thuật nào có thể rắc lên nó để làm cho nó biến mất. Tuy nhiên, chúng ta có thể suy nghĩ lại vấn đề và đạt được thỏa hiệp.
Sự thỏa hiệp này liên quan đến một mức độ tập trung nhất định. Chúng ta có thể sử dụng cơ chế nhật ký phân tán vì nó cung cấp các luồng đáng tin cậy và có thể mở rộng. Hiện tại, chúng tôi muốn các dịch vụ có thể tham gia và hoạt động trên các luồng chia sẻ này, nhưng chúng tôi muốn tránh các Dịch vụ của Chúa tập trung phức tạp thực hiện quá trình xử lý này. Do đó, lựa chọn tốt nhất là xây dựng quy trình xử lý luồng vào từng dịch vụ tiêu dùng. Bằng cách này, các dịch vụ sẽ có thể kết hợp các tập dữ liệu từ nhiều nguồn khác nhau và làm việc với chúng theo cách họ cần.
Một cách để đạt được phương pháp này là thông qua việc sử dụng nền tảng phát trực tuyến. Có nhiều lựa chọn, nhưng hôm nay chúng ta sẽ xem xét Kafka, vì việc sử dụng Xử lý luồng trạng thái của nó cho phép chúng ta giải quyết một cách hiệu quả vấn đề đã trình bày.
Việc sử dụng cơ chế ghi nhật ký phân tán cho phép chúng tôi đi theo con đường quen thuộc và sử dụng tính năng nhắn tin để làm việc với . Cách tiếp cận này được coi là cung cấp khả năng mở rộng và phân vùng tốt hơn cơ chế phản hồi yêu cầu vì nó cho phép kiểm soát luồng đến người nhận thay vì người gửi. Tuy nhiên, mọi thứ trong cuộc sống này bạn đều phải trả tiền, và ở đây bạn cần một người môi giới. Nhưng đối với các hệ thống lớn, sự đánh đổi là xứng đáng (điều này có thể không xảy ra đối với ứng dụng web thông thường của bạn).
Nếu nhà môi giới chịu trách nhiệm ghi nhật ký phân tán thay vì hệ thống nhắn tin truyền thống, bạn có thể tận dụng các tính năng bổ sung. Việc vận chuyển có thể mở rộng tuyến tính gần như một hệ thống tệp phân tán. Dữ liệu có thể được lưu trữ trong nhật ký trong một thời gian khá dài, vì vậy chúng tôi không chỉ nhận được sự trao đổi tin nhắn mà còn lưu trữ thông tin. Lưu trữ có thể mở rộng mà không sợ trạng thái chia sẻ có thể thay đổi.
Sau đó, bạn có thể sử dụng xử lý luồng trạng thái để thêm các công cụ cơ sở dữ liệu khai báo vào các dịch vụ tiêu thụ. Đây là một ý tưởng rất quan trọng. Mặc dù dữ liệu được lưu trữ trong các luồng chung mà tất cả các dịch vụ đều có thể truy cập, nhưng việc tổng hợp và xử lý dịch vụ đó là riêng tư. Họ thấy mình bị cô lập trong một bối cảnh hạn chế nghiêm ngặt.
Loại bỏ sự phân đôi dữ liệu bằng cách tách dòng trạng thái bất biến. Sau đó, thêm chức năng này vào mọi dịch vụ bằng cách sử dụng Xử lý luồng trạng thái.
Do đó, nếu dịch vụ của bạn cần làm việc với các đơn đặt hàng, danh mục sản phẩm, kho hàng, thì dịch vụ đó sẽ có toàn quyền truy cập: chỉ bạn mới quyết định dữ liệu nào sẽ kết hợp, xử lý dữ liệu đó ở đâu và dữ liệu đó sẽ thay đổi như thế nào theo thời gian. Mặc dù thực tế là dữ liệu được chia sẻ nhưng hoạt động với nó hoàn toàn được phân cấp. Nó được sản xuất trong mỗi dịch vụ, trong một thế giới nơi mọi thứ đều tuân theo quy tắc của bạn.
Chia sẻ dữ liệu mà không ảnh hưởng đến tính toàn vẹn của nó. Đóng gói chức năng chứ không phải nguồn trong mọi dịch vụ cần đến nó.
Nó xảy ra rằng dữ liệu cần phải được di chuyển hàng loạt. Đôi khi một dịch vụ yêu cầu tập dữ liệu lịch sử cục bộ trong công cụ cơ sở dữ liệu đã chọn. Bí quyết là bạn có thể đảm bảo rằng, nếu cần, một bản sao có thể được khôi phục từ nguồn bằng cách truy cập cơ chế ghi nhật ký phân tán. Các trình kết nối trong Kafka thực hiện rất tốt việc này.
Vì vậy, cách tiếp cận được thảo luận hôm nay có một số ưu điểm:
- Dữ liệu được sử dụng dưới dạng luồng chung, có thể được lưu trữ trong nhật ký trong thời gian dài và cơ chế làm việc với dữ liệu chung được gắn cứng trong từng bối cảnh riêng lẻ, cho phép các dịch vụ hoạt động dễ dàng và nhanh chóng. Bằng cách này, sự phân đôi của dữ liệu có thể được cân bằng.
- Dữ liệu đến từ các dịch vụ khác nhau có thể dễ dàng kết hợp thành bộ. Điều này giúp đơn giản hóa việc tương tác với dữ liệu được chia sẻ và loại bỏ nhu cầu duy trì các tập dữ liệu cục bộ trong cơ sở dữ liệu.
- Xử lý luồng trạng thái chỉ lưu trữ dữ liệu và nguồn sự thật vẫn là nhật ký chung, do đó vấn đề hỏng dữ liệu theo thời gian không quá nghiêm trọng.
- Về cốt lõi, các dịch vụ được điều khiển dựa trên dữ liệu, nghĩa là mặc dù khối lượng dữ liệu ngày càng tăng, các dịch vụ vẫn có thể phản hồi nhanh chóng với các sự kiện kinh doanh.
- Các vấn đề về khả năng mở rộng thuộc về nhà môi giới chứ không phải dịch vụ. Điều này làm giảm đáng kể sự phức tạp của dịch vụ viết vì không cần phải suy nghĩ về khả năng mở rộng.
- Việc thêm dịch vụ mới không yêu cầu phải thay đổi dịch vụ cũ nên việc kết nối dịch vụ mới trở nên dễ dàng hơn.
Như bạn có thể thấy, đây không chỉ là REST. Chúng tôi đã nhận được một bộ công cụ cho phép bạn làm việc với dữ liệu được chia sẻ theo cách phi tập trung.
Không phải tất cả các khía cạnh đều được đề cập trong bài viết hôm nay. Chúng ta vẫn cần tìm ra cách cân bằng giữa mô hình phản hồi yêu cầu và mô hình hướng sự kiện. Nhưng lần sau chúng ta sẽ giải quyết vấn đề này. Có những chủ đề mà bạn cần tìm hiểu rõ hơn, chẳng hạn như tại sao Xử lý luồng trạng thái lại tốt đến vậy. Chúng ta sẽ nói về điều này trong bài viết thứ ba. Và có những cấu trúc mạnh mẽ khác mà chúng ta có thể tận dụng nếu sử dụng chúng, chẳng hạn như . Nó là yếu tố thay đổi cuộc chơi cho các hệ thống kinh doanh phân tán vì nó cung cấp sự đảm bảo về giao dịch cho ở dạng có thể mở rộng. Điều này sẽ được thảo luận trong bài viết thứ tư. Cuối cùng, chúng ta sẽ cần xem xét chi tiết việc triển khai các nguyên tắc này.
Nhưng hiện tại, hãy nhớ điều này: sự phân đôi dữ liệu là một áp lực mà chúng ta phải đối mặt khi xây dựng các dịch vụ kinh doanh. Và chúng ta phải nhớ điều này. Bí quyết là đảo ngược mọi thứ và bắt đầu xử lý dữ liệu được chia sẻ như các đối tượng hạng nhất. Xử lý luồng trạng thái cung cấp một sự thỏa hiệp duy nhất cho việc này. Nó tránh được “Các thành phần thần thánh” tập trung làm cản trở sự tiến bộ. Hơn nữa, nó đảm bảo tính linh hoạt, khả năng mở rộng và khả năng phục hồi của các đường truyền dữ liệu và bổ sung chúng vào mọi dịch vụ. Do đó, chúng ta có thể tập trung vào luồng ý thức chung mà bất kỳ dịch vụ nào cũng có thể kết nối và hoạt động với dữ liệu của nó. Điều này làm cho các dịch vụ có khả năng mở rộng hơn, có thể thay thế và tự chủ hơn. Vì vậy, chúng không chỉ trông đẹp mắt trên bảng trắng và các bài kiểm tra giả thuyết mà còn hoạt động và phát triển trong nhiều thập kỷ.
Nguồn: www.habr.com