Acknowledgments from Mark Richards

Ngoài những lời cảm ơn đã được đề cập trước đó, tôi một lần nữa cảm ơn người vợ đáng yêu của tôi, Rebecca, vì đã kiên nhẫn với tôi trong một dự án sách nữa. Sự hỗ trợ và lời khuyên không ngừng của bạn đã giúp cuốn sách này trở thành hiện thực, ngay cả khi điều đó có nghĩa là phải dành thời gian cho việc viết tiểu thuyết của bạn. Bạn có ý nghĩa rất lớn đối với tôi, Rebecca. Tôi cũng cảm ơn người bạn tốt và đồng tác giả của tôi, Neal Ford. Sự hợp tác với bạn trong các tài liệu cho cuốn sách này (cũng như cuốn trước đó) thực sự là một trải nghiệm quý giá và đầy ý nghĩa. Bạn là, và luôn luôn là, bạn của tôi.

Acknowledgments from Neal Ford

Tôi muốn cảm ơn gia đình mở rộng của mình, Thoughtworks như một tập thể, và Rebecca Parsons cùng Martin Fowler như những phần cá nhân trong đó. Thoughtworks là một nhóm người phi thường, họ có khả năng tạo ra giá trị cho khách hàng trong khi luôn chú ý đến lý do tại sao mọi thứ hoạt động để chúng ta có thể cải thiện chúng. Thoughtworks đã hỗ trợ cuốn sách này theo nhiều cách và tiếp tục nuôi dưỡng những Thoughtworkers thách thức và truyền cảm hứng cho tôi mỗi ngày. Tôi cũng cảm ơn câu lạc bộ cocktail khu phố của chúng tôi vì những giờ thoát khỏi nhịp sống thường nhật, bao gồm cả các phiên họp ngoài trời hàng tuần, khoảng cách xã hội mà đã giúp tất cả chúng tôi vượt qua khoảng thời gian kỳ lạ vừa qua. Tôi cảm ơn người bạn lâu năm của tôi, Norman Zapien, người luôn mang đến những cuộc trò chuyện thú vị. Cuối cùng, tôi cảm ơn vợ tôi, Candy, người tiếp tục hỗ trợ lối sống này mà khiến tôi phải tập trung vào những thứ như viết sách hơn là chú ý quá nhiều đến những chú mèo của chúng tôi.

Acknowledgments from Pramod Sadalage

Tôi cảm ơn vợ tôi, Rupali, vì tất cả sự hỗ trợ và hiểu biết, và hai cô gái đáng yêu của tôi, Arula và Arhana, vì sự khuyến khích; bố yêu cả hai con. Tất cả công việc tôi làm sẽ không thể thực hiện được nếu không có các khách hàng mà tôi làm việc cùng và các hội nghị khác nhau đã giúp tôi phát triển các khái niệm và nội dung. Tôi cảm ơn AvidXchange, khách hàng mới nhất mà tôi đang làm việc, vì sự hỗ trợ và cung cấp không gian tuyệt vời để phát triển các khái niệm mới. Tôi cũng cảm ơn Thoughtworks vì sự hỗ trợ liên tục trong cuộc sống của tôi, và Neal Ford, Rebecca Parsons, và Martin Fowler vì đã là những người cố vấn tuyệt vời; các bạn làm tôi trở thành một người tốt hơn. Cuối cùng, tôi xin cảm ơn cha mẹ tôi, đặc biệt là mẹ tôi, Shobha, người mà tôi nhớ mỗi ngày. Con nhớ mẹ, MẸ.

Acknowledgments from Zhamak Dehghani

Tôi cảm ơn Mark và Neal vì lời mời mở để đóng góp vào tác phẩm tuyệt vời này. Đóng góp của tôi cho cuốn sách này sẽ không thể thực hiện được nếu không có sự hỗ trợ liên tục của chồng tôi, Adrian, và sự kiên nhẫn của con gái tôi, Arianna. Tôi yêu cả hai người.

Using Fitness Functions

Trong cuốn sách năm 2017 "Xây dựng Kiến trúc Tiến hóa" (O’Reilly), các tác giả (Neal Ford, Rebecca Parsons và Patrick Kua) đã định nghĩa khái niệm về hàm thích nghi kiến trúc: bất kỳ cơ chế nào thực hiện đánh giá tính toàn vẹn khách quan của một số đặc điểm kiến trúc hoặc sự kết hợp của các đặc điểm kiến trúc. Dưới đây là phân tích từng điểm của định nghĩa đó:

Any mechanism

Các kiến trúc sư có thể sử dụng một loạt các công cụ để triển khai các hàm fitness; chúng tôi sẽ trình bày nhiều ví dụ trong suốt cuốn sách. Ví dụ, có những thư viện kiểm thử chuyên dụng để kiểm tra cấu trúc kiến trúc, các kiến trúc sư có thể sử dụng các công cụ giám sát để kiểm tra các đặc điểm kiến trúc hoạt động như hiệu suất hoặc khả năng mở rộng, và các khung kỹ thuật chắn tán kiểm tra độ tin cậy và khả năng phục hồi.

Objective integrity assessment

Một yếu tố quan trọng cho quản trị tự động nằm ở các định nghĩa khách quan cho các đặc điểm kiến trúc. Ví dụ, một kiến trúc sư không thể chỉ định rằng họ muốn một trang web "hiệu suất cao"; họ phải cung cấp một giá trị đối tượng có thể được đo lường bằng một bài kiểm tra, giám sát hoặc chức năng phù hợp khác.

Các kiến trúc sư cần chú ý đến các đặc điểm của kiến trúc tổng hợp—những đặc điểm không thể đo lường một cách khách quan nhưng thực sự là sự tổng hợp của các yếu tố có thể đo lường khác. Chẳng hạn, "tính linh hoạt" không thể đo lường được, nhưng nếu một kiến trúc sư bắt đầu phân tích khái niệm rộng này, mục tiêu là các đội ngũ có thể phản ứng nhanh chóng và tự tin với sự thay đổi, bất kể là trong hệ sinh thái hay lĩnh vực nào. Do đó, một kiến trúc sư có thể tìm ra các đặc điểm có thể đo lường góp phần vào tính linh hoạt: khả năng triển khai, khả năng kiểm tra, thời gian chu trình, và nhiều hơn nữa. Thường thì, việc thiếu khả năng đo lường một đặc điểm kiến trúc cho thấy định nghĩa đó quá mơ hồ. Nếu các kiến trúc sư hướng tới các thuộc tính có thể đo lường, điều này cho phép họ tự động hóa việc áp dụng chức năng phù hợp.

Some architecture characteristic or combination of architecture characteristics

Đặc điểm này mô tả hai phạm vi cho các hàm fitness:

Atomic

Các hàm fitness này xử lý một đặc điểm kiến trúc đơn lẻ một cách tách biệt. Ví dụ, một hàm fitness kiểm tra vòng lặp thành phần trong một mã nguồn là có phạm vi nguyên tử.

Holistic

Các chức năng thể dục toàn diện xác thực sự kết hợp của các đặc điểm kiến trúc. Một yếu tố làm phức tạp các đặc điểm kiến trúc là sự hợp tác mà chúng đôi khi thể hiện với các đặc điểm kiến trúc khác. Ví dụ, nếu một kiến trúc sư muốn cải thiện bảo mật, có khả năng cao rằng điều đó sẽ ảnh hưởng đến hiệu suất. Tương tự, tính mở rộng và tính linh hoạt đôi khi mâu thuẫn với nhau - việc hỗ trợ một số lượng lớn người dùng đồng thời có thể khiến việc xử lý các đột biến đột ngột trở nên khó khăn hơn. Các chức năng thể dục toàn diện vận hành một sự kết hợp của các đặc điểm kiến trúc liên kết để đảm bảo rằng hiệu ứng kết hợp sẽ không ảnh hưởng tiêu cực đến kiến trúc.

Một kiến trúc sư triển khai các hàm fitness để xây dựng các biện pháp bảo vệ xung quanh sự thay đổi bất ngờ trong các đặc điểm kiến trúc. Trong thế giới phát triển phần mềm Agile, các nhà phát triển triển khai các bài kiểm tra đơn vị, chức năng và chấp nhận người dùng để xác thực các khía cạnh khác nhau của thiết kế miền. Tuy nhiên, cho đến nay, chưa có cơ chế tương tự nào tồn tại để xác thực phần đặc điểm kiến trúc của thiết kế. Thật vậy, sự tách biệt giữa các hàm fitness và các bài kiểm tra đơn vị cung cấp một hướng dẫn phạm vi tốt cho các kiến trúc sư. Các hàm fitness xác thực các đặc điểm kiến trúc, không phải tiêu chí miền; các bài kiểm tra đơn vị thì ngược lại. Do đó, một kiến trúc sư có thể quyết định xem cần hàm fitness hay bài kiểm tra đơn vị bằng cách đặt câu hỏi: “Có cần bất kỳ kiến thức miền nào để thực hiện bài kiểm tra này không?” Nếu câu trả lời là “có”, thì bài kiểm tra đơn vị/chức năng/chấp nhận người dùng là phù hợp; nếu “không”, thì một hàm fitness là cần thiết.

Chẳng hạn, khi các kiến trúc sư nói về tính đàn hồi, đó là khả năng của ứng dụng để chịu đựng một lượng người dùng đột ngột tăng cao. Lưu ý rằng kiến trúc sư không cần biết bất kỳ chi tiết nào về miền—điều này có thể là một trang web thương mại điện tử, một trò chơi trực tuyến, hoặc một thứ gì khác. Do đó, tính đàn hồi là mối quan tâm về kiến trúc và nằm trong phạm vi của một hàm sức khỏe. Ngược lại, nếu kiến trúc sư muốn xác thực các phần đúng của một địa chỉ gửi thư, điều đó được bao phủ thông qua một bài kiểm tra truyền thống. Tất nhiên, sự phân tách này không hoàn toàn nhị nguyên—một số hàm sức khỏe sẽ chạm đến miền và ngược lại, nhưng các mục tiêu khác nhau cung cấp một cách tốt để tách biệt chúng một cách tâm lý.

Dưới đây là một vài ví dụ để làm cho khái niệm bớt trừu tượng.

Một mục tiêu phổ biến của kiến trúc sư là duy trì tính toàn vẹn cấu trúc nội bộ tốt trong mã nguồn. Tuy nhiên, những lực lượng xấu hoạt động chống lại ý định tốt của kiến trúc sư trên nhiều nền tảng. Ví dụ, khi lập trình trong bất kỳ môi trường phát triển Java hoặc .NET phổ biến nào, ngay khi một lập trình viên tham chiếu đến một lớp chưa được nhập khẩu, IDE sẽ hữu ích trình bày một hộp thoại hỏi lập trình viên xem họ có muốn tự động nhập tham chiếu không. Điều này xảy ra thường xuyên đến mức hầu hết các lập trình viên phát triển thói quen gạt bỏ hộp thoại tự động nhập như một phản xạ.

Tuy nhiên, việc nhập khẩu tùy tiện các lớp hoặc thành phần với nhau sẽ dẫn đến thảm họa cho tính module. Ví dụ, Hình 1-1 minh họa một mẫu phản tác dụng đặc biệt nghiêm trọng mà các kiến trúc sư mong muốn tránh.

Figure 1-1. Cyclic dependencies between components

Trong mẫu chống ví dụ này, mỗi thành phần tham chiếu đến một thứ gì đó trong các thành phần khác. Việc có một mạng lưới các thành phần như vậy làm hỏng tính mô-đun vì một nhà phát triển không thể tái sử dụng một thành phần đơn lẻ mà không mang theo các thành phần khác. Và, dĩ nhiên, nếu các thành phần khác được liên kết với các thành phần khác, kiến trúc có xu hướng ngày càng tiến tới mẫu chống ví dụ Big Ball of Mud. Làm thế nào các kiến trúc sư có thể quản lý hành vi này mà không phải liên tục nhìn qua vai của các nhà phát triển nhanh nhạy? Đánh giá mã giúp nhưng diễn ra quá muộn trong chu kỳ phát triển để có hiệu quả. Nếu một kiến trúc sư cho phép một nhóm phát triển tự do nhập khẩu qua mã trong một tuần cho đến khi đánh giá mã, thiệt hại nghiêm trọng đã xảy ra trong mã.

Giải pháp cho vấn đề này là viết một hàm phù hợp để tránh các chu trình thành phần, như được trình bày trong Ví dụ 1-1.

public class CycleTest { private JDepend jdepend; @BeforeEach void init() { jdepend = new JDepend(); jdepend.addDirectory("/path/to/project/persistence/classes"); jdepend.addDirectory("/path/to/project/web/classes"); jdepend.addDirectory("/path/to/project/thirdpartyjars"); } @Test void testAllPackages() { Collection packages = jdepend.analyze(); assertEquals("Cycles exist", false, jdepend.containsCycles()); } }

Trong mã, một kiến trúc sư sử dụng công cụ đo lường JDepend để kiểm tra các phụ thuộc giữa các gói. Công cụ này hiểu cấu trúc của các gói Java và sẽ thất bại trong bài kiểm tra nếu có bất kỳ chu kỳ nào tồn tại. Một kiến trúc sư có thể kết nối bài kiểm tra này vào quá trình xây dựng liên tục của một dự án và ngừng lo lắng về việc các nhà phát triển dễ dàng tạo ra các chu kỳ một cách tình cờ. Đây là một ví dụ tuyệt vời về một hàm fitness bảo vệ các thực hành quan trọng hơn là khẩn cấp trong phát triển phần mềm: đó là một mối quan tâm quan trọng đối với các kiến trúc sư, nhưng lại có ít tác động đến việc lập trình hàng ngày.

Ví dụ 1-1 cho thấy một hàm fitness rất cấp thấp, tập trung vào mã nguồn. Nhiều công cụ bảo trì mã nguồn phổ biến (chẳng hạn như SonarQube) triển khai nhiều hàm fitness thường gặp theo cách sẵn có. Tuy nhiên, các kiến trúc sư cũng có thể muốn xác nhận cấu trúc vĩ mô của kiến trúc cũng như cấu trúc vi mô. Khi thiết kế một kiến trúc theo lớp như trong Hình 1-2, kiến trúc sư xác định các lớp để đảm bảo sự tách biệt của các mối quan tâm.

Figure 1-2. Traditional layered architecture

Tuy nhiên, làm thế nào kiến trúc sư có thể đảm bảo rằng các lập trình viên sẽ tôn trọng những lớp này? Một số lập trình viên có thể không hiểu tầm quan trọng của các mẫu, trong khi những người khác có thể áp dụng thái độ "thà xin lỗi còn hơn xin phép" do một số mối quan tâm địa phương vượt trội, chẳng hạn như hiệu suất. Nhưng cho phép những người thực hiện làm yếu đi lý do cho kiến trúc sẽ gây hại cho sức khỏe lâu dài của kiến trúc.

ArchUnit cho phép các kiến trúc sư giải quyết vấn đề này thông qua một hàm đánh giá, được trình bày trong Ví dụ 1-2.

layeredArchitecture() .layer("Controller").definedBy("..controller..") .layer("Service").definedBy("..service..") .layer("Persistence").definedBy("..persistence..") .whereLayer("Controller").mayNotBeAccessedByAnyLayer() .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller") .whereLayer("Persistence").mayOnlyBeAccessedByLayers("Service")

Trong Ví dụ 1-2, kiến trúc sư xác định mối quan hệ mong muốn giữa các lớp và viết một hàm kiểm tra độ phù hợp để quản lý điều đó. Điều này cho phép kiến trúc sư thiết lập các nguyên tắc kiến trúc bên ngoài các sơ đồ và các tài liệu thông tin khác, cũng như xác minh chúng một cách liên tục.

Một công cụ tương tự trong không gian .NET, NetArchTest, cho phép thực hiện các bài kiểm tra tương tự cho nền tảng đó. Một xác minh lớp trong C# xuất hiện trong Ví dụ 1-3.

// Classes in the presentation should not directly reference repositories var result = Types.InCurrentDomain() .That() .ResideInNamespace("NetArchTest.SampleLibrary.Presentation") .ShouldNot() .HaveDependencyOn("NetArchTest.SampleLibrary.Data") .GetResult() .IsSuccessful;

Các công cụ tiếp tục xuất hiện trong lĩnh vực này với mức độ tinh vi ngày càng tăng. Chúng tôi sẽ tiếp tục làm nổi bật nhiều kỹ thuật trong số này khi chúng tôi minh họa các hàm thích nghi cùng với nhiều giải pháp của chúng tôi.

Việc tìm kiếm một kết quả khách quan cho một hàm fitness là rất quan trọng. Tuy nhiên, khách quan không có nghĩa là tĩnh. Một số hàm fitness sẽ có giá trị trả về phi ngữ cảnh, chẳng hạn như đúng/sai hoặc một giá trị số như ngưỡng hiệu suất. Tuy nhiên, các hàm fitness khác (được coi là động) sẽ trả về một giá trị dựa trên một số ngữ cảnh. Ví dụ, khi đo lường khả năng mở rộng, các kiến trúc sư đo lường số lượng người dùng đồng thời và cũng thường đo lường hiệu suất cho mỗi người dùng. Thường thì, các kiến trúc sư thiết kế hệ thống sao cho khi số lượng người dùng tăng lên, hiệu suất mỗi người dùng giảm nhẹ — nhưng không rơi mạnh. Do đó, đối với những hệ thống này, các kiến trúc sư thiết kế các hàm fitness về hiệu suất tính đến số lượng người dùng đồng thời. Chừng nào mà việc đo lường một đặc điểm kiến trúc là khách quan, các kiến trúc sư có thể kiểm tra nó.

Trong khi hầu hết các hàm thích nghi nên được tự động hóa và chạy liên tục, một số hàm sẽ cần phải được thực hiện thủ công. Một hàm thích nghi thủ công yêu cầu một người xử lý việc xác thực. Ví dụ, đối với các hệ thống có thông tin pháp lý nhạy cảm, một luật sư có thể cần kiểm tra các thay đổi ở các phần quan trọng để đảm bảo tính hợp pháp, mà việc này không thể tự động hóa. Hầu hết các pipeline triển khai hỗ trợ các giai đoạn thủ công, cho phép các nhóm điều chỉnh các hàm thích nghi thủ công. Lý tưởng nhất, những giai đoạn này nên được thực hiện thường xuyên nhất có thể - một xác thực không chạy thì không thể xác thực được gì. Các nhóm thực hiện các hàm thích nghi theo yêu cầu (hiếm khi) hoặc như một phần của quy trình tích hợp liên tục (thường gặp). Để đạt được đầy đủ lợi ích của các xác thực như hàm thích nghi, chúng nên được thực hiện liên tục.

Tính liên tục là quan trọng, như được minh họa trong ví dụ về quản trị cấp doanh nghiệp sử dụng các hàm fitness. Hãy xem xét kịch bản sau: công ty sẽ làm gì khi phát hiện một lỗ hổng zero-day trong một trong các framework hoặc thư viện phát triển mà doanh nghiệp sử dụng? Nếu giống như hầu hết các công ty, các chuyên gia bảo mật sẽ rà soát các dự án để tìm phiên bản gây ra vấn đề của framework và đảm bảo nó được cập nhật, nhưng quy trình đó hiếm khi được tự động hóa, phụ thuộc vào nhiều bước thủ công. Đây không phải là một câu hỏi trừu tượng; kịch bản chính xác này đã ảnh hưởng đến một tổ chức tài chính lớn được mô tả trong Vụ rò rỉ dữ liệu của Equifax. Giống như quản trị kiến trúc được mô tả trước đó, các quy trình thủ công dễ mắc sai sót và cho phép các chi tiết bị bỏ qua.

Hãy tưởng tượng một thế giới khác, trong đó mọi dự án đều có một pipeline triển khai, và nhóm bảo mật có một “slot” trong pipeline triển khai của từng nhóm, nơi họ có thể triển khai các chức năng kiểm tra. Hầu hết thời gian, những kiểm tra này sẽ là những kiểm tra thông thường nhằm bảo đảm như ngăn cản các lập trình viên lưu trữ mật khẩu trong cơ sở dữ liệu và những công việc quản lý thông thường khác. Tuy nhiên, khi một lỗ hổng zero-day xuất hiện, việc có cùng một cơ chế ở mọi nơi cho phép nhóm bảo mật chèn một bài kiểm tra vào từng dự án nhằm kiểm tra một phiên bản và framework nhất định; nếu phát hiện phiên bản nguy hiểm, nó sẽ làm hỏng quá trình biên dịch và thông báo cho nhóm bảo mật. Các đội ngũ cấu hình pipeline triển khai để kích hoạt bất kỳ thay đổi nào trong hệ sinh thái: mã nguồn, sơ đồ cơ sở dữ liệu, cấu hình triển khai và các chức năng kiểm tra. Điều này cho phép các doanh nghiệp tự động hóa một cách phổ quát các nhiệm vụ quản lý quan trọng.

Các hàm đánh giá mang lại nhiều lợi ích cho các kiến trúc sư, không chỉ đơn thuần là cơ hội để họ lại có thể lập trình! Một trong những phàn nàn chung của các kiến trúc sư là họ ít có cơ hội lập trình hơn trước—nhưng các hàm đánh giá thường chính là mã nguồn! Bằng cách xây dựng một đặc tả có thể thực thi của kiến trúc, mà bất kỳ ai cũng có thể xác minh bất cứ lúc nào bằng cách chạy quá trình xây dựng của dự án, các kiến trúc sư phải hiểu rõ hệ thống và sự phát triển liên tục của nó, điều này có sự trùng lặp với mục tiêu cốt lõi là theo kịp mã nguồn của dự án khi nó phát triển.

Tuy nhiên, bất kỳ hàm fitness nào mạnh mẽ đến đâu, các kiến trúc sư cũng nên tránh lạm dụng chúng. Các kiến trúc sư không nên hình thành một nhóm và rút lui vào một tháp ngà để xây dựng một tập hợp các hàm fitness phức tạp, liên kết với nhau đến mức không thể nào thực hiện được, chỉ gây frust cho các nhà phát triển và các nhóm. Thay vào đó, đây là cách để các kiến trúc sư xây dựng một danh sách kiểm tra có thể thực thi của các nguyên tắc quan trọng nhưng không khẩn cấp trong các dự án phần mềm. Nhiều dự án chìm trong sự cấp bách, khiến một số nguyên tắc quan trọng bị rơi rụng. Điều này thường là nguyên nhân của nợ kỹ thuật: "Chúng tôi biết đây là xấu, nhưng chúng tôi sẽ quay lại để sửa chữa sau"—và sau đó không bao giờ đến. Bằng cách quy định các quy tắc về chất lượng mã, cấu trúc, và các biện pháp bảo vệ khác chống lại sự xuống cấp thành các hàm fitness chạy liên tục, các kiến trúc sư xây dựng một danh sách kiểm tra chất lượng mà các nhà phát triển không thể bỏ qua.

Vài năm trước, cuốn sách tuyệt vời "The Checklist Manifesto" của Atul Gawande (Picador) đã nhấn mạnh việc sử dụng danh sách kiểm tra của các chuyên gia như bác sĩ phẫu thuật, phi công và những lĩnh vực khác mà thường xuyên sử dụng (đôi khi theo yêu cầu của pháp luật) danh sách kiểm tra như một phần trong công việc của họ. Điều này không phải vì họ không biết công việc của mình hay đặc biệt hay quên; khi các chuyên gia thực hiện cùng một nhiệm vụ lặp đi lặp lại, rất dễ để tự lừa dối bản thân khi vô tình bỏ qua, và danh sách kiểm tra ngăn chặn điều đó. Các chức năng thể hình đại diện cho một danh sách kiểm tra các nguyên tắc quan trọng được định nghĩa bởi các kiến trúc sư và được thực thi như một phần của quy trình xây dựng để đảm bảo các nhà phát triển không vô tình (hoặc có chủ đích, do các yếu tố bên ngoài như áp lực về tiến độ) bỏ qua chúng.

Chúng tôi sử dụng các hàm fitness xuyên suốt cuốn sách khi có cơ hội để minh họa việc quản lý một giải pháp kiến trúc cũng như thiết kế ban đầu.

Nonticketing Workflow

Các quy trình không liên quan đến vé bao gồm những hành động mà các quản trị viên, quản lý và khách hàng thực hiện không liên quan đến một vé vấn đề. Các quy trình này được mô tả như sau:

1. Các chuyên gia của Đội ngũ Sysops được thêm vào và duy trì trong hệ thống thông qua một quản trị viên, người nhập khu vực, tính khả dụng và kỹ năng của họ.

2. Khách hàng đăng ký với hệ thống Sysops Squad và có nhiều kế hoạch hỗ trợ dựa trên các sản phẩm họ đã mua.

3. Khách hàng sẽ được tự động tính phí hàng tháng dựa trên thông tin thẻ tín dụng trong hồ sơ của họ. Khách hàng có thể xem lịch sử thanh toán và bảng sao kê qua hệ thống.

4. Các quản lý yêu cầu và nhận các báo cáo hoạt động và phân tích đa dạng, bao gồm báo cáo tài chính, báo cáo hiệu suất chuyên gia và báo cáo vé.

Ticketing Workflow

Quy trình ticket bắt đầu khi một khách hàng nhập một vé vấn đề vào hệ thống và kết thúc khi khách hàng hoàn thành khảo sát sau khi sửa chữa xong. Quy trình này được phác thảo như sau:

1. Khách hàng đã mua gói hỗ trợ sẽ tạo một vé báo lỗi bằng cách sử dụng trang web Sysops Squad.

2. Ngay khi một phiếu yêu cầu sự cố được nhập vào hệ thống, hệ thống sẽ xác định chuyên gia của Đội Sysops nào sẽ phù hợp nhất với công việc dựa trên kỹ năng, vị trí hiện tại, khu vực dịch vụ và khả năng sẵn sàng.

3. Khi được phân công, vé sự cố sẽ được tải lên một ứng dụng di động tùy chỉnh trên thiết bị di động của chuyên gia trong Đội ngũ Sysops. Chuyên gia cũng sẽ nhận được thông báo qua tin nhắn văn bản rằng họ có một vé sự cố mới.

4. Khách hàng được thông báo qua tin nhắn SMS hoặc email (dựa trên sở thích trong hồ sơ của họ) rằng chuyên gia đang trên đường đến.

5. Chuyên gia sử dụng ứng dụng di động tùy chỉnh trên điện thoại của họ để lấy thông tin vé và vị trí. Chuyên gia của nhóm Sysops cũng có thể truy cập cơ sở kiến thức thông qua ứng dụng di động để tìm hiểu những gì đã được thực hiện trong quá khứ để khắc phục vấn đề.

6. Khi chuyên gia khắc phục vấn đề, họ sẽ đánh dấu vé là “hoàn thành.” Chuyên gia của nhóm sysops có thể sau đó thêm thông tin về vấn đề và sửa chữa cơ sở dữ liệu tri thức.

7. Sau khi hệ thống nhận được thông báo rằng vé đã hoàn thành, nó sẽ gửi email đến khách hàng với liên kết đến một cuộc khảo sát, mà khách hàng sau đó sẽ điền vào.

8. Hệ thống nhận bảng khảo sát đã hoàn thành từ khách hàng và ghi lại thông tin khảo sát.

A Bad Scenario

Gần đây, tình hình với ứng dụng xử lý vé sự cố của đội Sysops không tốt. Hệ thống vé sự cố hiện tại là một ứng dụng khổng lồ, được phát triển cách đây nhiều năm. Khách hàng phàn nàn rằng các tư vấn viên không bao giờ xuất hiện vì vé bị mất, và thường thì tư vấn viên sai xuất hiện để sửa chữa những thứ họ không biết gì về nó. Khách hàng cũng đã phàn nàn rằng hệ thống không luôn sẵn sàng để nhập vé sự cố mới.

Thay đổi cũng khó khăn và rủi ro trong tổ chức lớn này. Mỗi khi có một thay đổi được thực hiện, thường mất quá nhiều thời gian và thường có một thứ khác bị hỏng. Do các vấn đề về độ tin cậy, hệ thống Đội ngũ Sysops thường xuyên "bị đóng băng" hoặc gặp sự cố, dẫn đến việc toàn bộ tính năng ứng dụng không khả dụng từ năm phút đến hai giờ trong khi vấn đề được xác định và ứng dụng được khởi động lại.

Nếu không có biện pháp gì được thực hiện sớm, Penultimate Electronics sẽ buộc phải từ bỏ mảng kinh doanh hợp đồng hỗ trợ rất có lãi và sa thải tất cả các quản trị viên, chuyên gia, quản lý và nhân viên phát triển CNTT của đội Sysops Squad—bao gồm cả các kiến trúc sư.

Sysops Squad Architectural Components

Hệ thống đơn thể cho ứng dụng Sysops Squad xử lý quản lý vé, báo cáo hoạt động, đăng ký khách hàng và lập hóa đơn, cũng như các chức năng hành chính chung như bảo trì người dùng, đăng nhập, và duy trì kỹ năng và hồ sơ chuyên gia. Hình 1-3 và Bảng 1-1 tương ứng minh họa và mô tả các thành phần của ứng dụng đơn thể hiện có (phần ss. của không gian tên xác định ngữ cảnh ứng dụng Sysops Squad).

Figure 1-3. Components within the existing Sysops Squad application

Các thành phần này sẽ được sử dụng trong các chương tiếp theo để minh họa các kỹ thuật và sự đánh đổi khác nhau khi xử lý việc chia nhỏ các ứng dụng thành kiến trúc phân tán.

Sysops Squad Data Model

Ứng dụng Sysops Squad cùng với các thành phần khác nhau được liệt kê trong Bảng 1-1 sử dụng một lược đồ duy nhất trong cơ sở dữ liệu để lưu trữ tất cả các bảng và mã cơ sở dữ liệu liên quan. Cơ sở dữ liệu này được sử dụng để lưu trữ thông tin về khách hàng, người dùng, hợp đồng, thanh toán, hóa đơn, cơ sở kiến thức và khảo sát khách hàng; các bảng được liệt kê trong Bảng 1-2, và mô hình ER được minh họa trong Hình 1-4.

Figure 1-4. Data model within the existing Sysops Squad application

Mô hình dữ liệu Sysops là một mô hình dữ liệu chuẩn ở dạng chuẩn ba bình thường với chỉ một vài thủ tục lưu trữ hoặc kích hoạt. Tuy nhiên, có khá nhiều view tồn tại chủ yếu được sử dụng bởi thành phần Báo cáo. Khi nhóm kiến trúc cố gắng phân tách ứng dụng và hướng tới kiến trúc phân tán, họ sẽ phải làm việc với nhóm cơ sở dữ liệu để hoàn thành các nhiệm vụ ở cấp độ cơ sở dữ liệu. Cấu trúc của các bảng và view trong cơ sở dữ liệu này sẽ được sử dụng xuyên suốt cuốn sách để thảo luận về các kỹ thuật và sự đánh đổi khác nhau nhằm thực hiện nhiệm vụ phân tách cơ sở dữ liệu.

Independently Deployable

Cái gọi là có thể triển khai độc lập ngụ ý nhiều khía cạnh của một quantum kiến trúc - mỗi quantum đại diện cho một đơn vị có thể triển khai riêng biệt trong một kiến trúc cụ thể. Do đó, một kiến trúc đơn khối - một kiến trúc được triển khai như một đơn vị duy nhất - theo định nghĩa là một quantum kiến trúc đơn. Trong một kiến trúc phân tán như microservices, các nhà phát triển có xu hướng hướng tới khả năng triển khai các dịch vụ một cách độc lập, thường là theo cách tự động hóa cao. Do đó, từ góc độ có thể triển khai độc lập, một dịch vụ trong kiến trúc microservices đại diện cho một quantum kiến trúc (tùy thuộc vào mức độ kết nối - như sẽ được thảo luận sau).

Việc làm cho mỗi kiến trúc lượng tử trở thành một tài sản có thể triển khai trong kiến trúc phục vụ nhiều mục đích hữu ích. Đầu tiên, ranh giới được đại diện bởi một kiến trúc lượng tử đóng vai trò như một ngôn ngữ chung hữu ích giữa các kiến trúc sư, nhà phát triển và đội ngũ vận hành. Mỗi người đều hiểu phạm vi chung đang được thảo luận: các kiến trúc sư hiểu các đặc tính liên kết, các nhà phát triển hiểu phạm vi hành vi, và đội ngũ vận hành hiểu các đặc tính có thể triển khai.

Thứ hai, kiến trúc lượng tử đại diện cho một trong những lực (kết hợp tĩnh) mà các kiến trúc sư phải xem xét khi cố gắng đạt được độ phân granularity phù hợp cho các dịch vụ trong một kiến trúc phân tán. Thường thì, trong các kiến trúc microservices, các nhà phát triển phải đối mặt với câu hỏi khó khăn về độ granularity của dịch vụ nào mang lại tập hợp tối ưu các sự trao đổi. Một số trong những sự trao đổi đó xoay quanh khả năng triển khai: chu kỳ phát hành mà dịch vụ này yêu cầu, những dịch vụ khác có thể bị ảnh hưởng, những thực tiễn kỹ thuật nào liên quan, và những điều tương tự. Các kiến trúc sư hưởng lợi từ việc hiểu rõ chính xác ranh giới triển khai nằm ở đâu trong các kiến trúc phân tán. Chúng tôi thảo luận về độ granularity của dịch vụ và các sự trao đổi liên quan trong Chương 7.

Thứ ba, khả năng triển khai độc lập buộc kiến trúc tách biệt phải bao gồm các điểm kết nối chung như cơ sở dữ liệu. Hầu hết các cuộc thảo luận về kiến trúc thường tiện lợi bỏ qua các vấn đề như cơ sở dữ liệu và giao diện người dùng, nhưng các hệ thống trong thế giới thực thường phải đối mặt với những vấn đề đó. Do đó, bất kỳ hệ thống nào sử dụng cơ sở dữ liệu chung đều không đạt tiêu chí kiến trúc cho khả năng triển khai độc lập trừ khi việc triển khai cơ sở dữ liệu diễn ra đồng bộ với ứng dụng. Nhiều hệ thống phân tán, nếu không chia sẻ cơ sở dữ liệu chung, sẽ đủ điều kiện cho nhiều phần kiến trúc nhưng lại không đạt yêu cầu triển khai độc lập nếu chúng chia sẻ một cơ sở dữ liệu chung có chu kỳ triển khai riêng. Do đó, chỉ đơn giản xem xét các ranh giới triển khai không cung cấp một thước đo hữu ích. Các kiến trúc sư cũng nên xem xét tiêu chí thứ hai cho một phần kiến trúc, đó là sự gắn kết chức năng cao, để giới hạn phần kiến trúc trong một phạm vi hữu ích.

High Functional Cohesion

Sự gắn kết chức năng cao về mặt cấu trúc đề cập đến sự gần gũi của các yếu tố liên quan: các lớp, thành phần, dịch vụ, và v.v. Trong suốt lịch sử, các nhà khoa học máy tính đã định nghĩa nhiều loại gắn kết, được giới hạn trong trường hợp này cho mô-đun tổng quát, có thể được đại diện dưới dạng các lớp hoặc thành phần, tùy thuộc vào nền tảng. Từ góc độ miền, định nghĩa kỹ thuật về sự gắn kết chức năng cao trùng lặp với các mục tiêu của ngữ cảnh giới hạn trong thiết kế theo miền: hành vi và dữ liệu thực hiện một quy trình làm việc cụ thể trong miền.

Từ góc độ khả năng triển khai độc lập hoàn toàn, một kiến trúc khổng lồ đơn thể đủ tư cách là một lượng kiến trúc. Tuy nhiên, nó gần như chắc chắn không có sự gắn kết chức năng cao, mà thay vào đó bao gồm chức năng của toàn bộ hệ thống. Kiến trúc đơn thể càng lớn, khả năng gắn kết chức năng đơn lẻ càng thấp.

Lý tưởng, trong kiến trúc microservices, mỗi dịch vụ mô hình hóa một miền hoặc quy trình đơn lẻ, do đó thể hiện sự gắn kết chức năng cao. Sự gắn kết trong bối cảnh này không phải là về cách các dịch vụ tương tác để thực hiện công việc, mà là cách một dịch vụ độc lập và liên kết với dịch vụ khác như thế nào.

High Static Coupling

Coupling tĩnh cao ngụ ý rằng các yếu tố bên trong kiến trúc lượng tử được kết nối chặt chẽ với nhau, điều này thực sự là một khía cạnh của các hợp đồng. Các kiến trúc sư nhận ra những điều như REST hoặc SOAP là các định dạng hợp đồng, nhưng các chữ ký phương thức và các phụ thuộc hoạt động (thông qua các điểm kết nối như địa chỉ IP hoặc URL) cũng đại diện cho các hợp đồng. Do đó, các hợp đồng là một phần khó của kiến trúc; chúng tôi sẽ đề cập đến các vấn đề liên quan đến việc kết nối bao gồm tất cả các loại hợp đồng, bao gồm cách chọn các hợp đồng phù hợp, trong Chương 13.

Một lượng kiến trúc (architecture quantum) là một phần của đo lường sự liên kết tĩnh, và phép đo này khá đơn giản cho hầu hết các topo kiến trúc. Ví dụ, các sơ đồ sau đây cho thấy các kiểu kiến trúc được đề cập trong cuốn "Nền tảng Kiến trúc Phần mềm", với sự liên kết tĩnh của lượng kiến trúc được minh họa.

Bất kỳ kiểu kiến trúc đơn khối nào cũng sẽ có một lượng bằng một, như được minh họa trong Hình 2-2.

Figure 2-2. Monolithic architectures always have a quantum of one

Như bạn có thể thấy, bất kỳ kiến trúc nào triển khai như một đơn vị duy nhất và sử dụng một cơ sở dữ liệu duy nhất sẽ luôn có một quantum duy nhất. Đo lường quantum kiến trúc của việc gắn kết tĩnh bao gồm cơ sở dữ liệu, và một hệ thống dựa vào một cơ sở dữ liệu duy nhất không thể có nhiều hơn một quantum. Do đó, đo lường gắn kết tĩnh của một quantum kiến trúc giúp xác định các điểm gắn kết trong kiến trúc, không chỉ trong các thành phần phần mềm đang phát triển. Hầu hết các kiến trúc đơn thể chứa một điểm gắn kết duy nhất (thường là một cơ sở dữ liệu) khiến cho đo lường quantum của nó bằng một.

Cấu trúc phân tán thường có đặc điểm tách rời ở cấp độ thành phần; hãy xem xét bộ các kiểu kiến trúc tiếp theo, bắt đầu với kiến trúc dựa trên dịch vụ được trình bày trong Hình 2-3.

Figure 2-3. Architecture quantum for a service-based architecture

Mặc dù mô hình dịch vụ cá nhân này cho thấy sự phân tách thường thấy trong kiến trúc microservices, nhưng kiến trúc vẫn sử dụng một cơ sở dữ liệu quan hệ duy nhất, khiến điểm số kiến trúc của nó chỉ đạt một.

Cho đến nay, việc đo lường sự ghép đôi tĩnh của kiến trúc lượng tử đã đánh giá tất cả các topo thành một. Tuy nhiên, các kiến trúc phân tán tạo ra khả năng có nhiều quanta nhưng không nhất thiết bảo đảm điều đó. Ví dụ, kiểu trung gian của kiến trúc điều khiển theo sự kiện sẽ luôn được đánh giá thành một kiến trúc lượng tử duy nhất, như được minh họa trong Hình 2-4.

Mặc dù kiểu kiến trúc này đại diện cho một kiến trúc phân tán, nhưng hai điểm kết nối kéo nó về phía một lượng kiến trúc đơn lẻ: cơ sở dữ liệu, giống như với các kiến trúc đơn thể trước đó, nhưng cũng là Bộ điều phối Yêu cầu chính nó - bất kỳ điểm kết nối toàn diện nào cần thiết cho kiến trúc hoạt động đều tạo thành một lượng kiến trúc xung quanh nó.

Figure 2-4. A mediated EDA has a single architecture quantum

Kiến trúc dựa trên sự kiện (không có trung gian trung tâm) ít bị phụ thuộc hơn, nhưng điều đó không đảm bảo sự tách biệt hoàn toàn. Hãy xem xét kiến trúc dựa trên sự kiện được minh họa trong Hình 2-5.

Kiến trúc theo kiểu môi giới (broker-style) dựa trên sự kiện này (không có một người trung gian trung tâm) vẫn được coi là một quantum kiến trúc duy nhất vì tất cả các dịch vụ đều sử dụng một cơ sở dữ liệu quan hệ duy nhất, đóng vai trò là một điểm nối chung. Câu hỏi được phân tích tĩnh cho một quantum kiến trúc là: “Liệu sự phụ thuộc này của kiến trúc có cần thiết để khởi động dịch vụ này không?” Ngay cả trong trường hợp một kiến trúc dựa trên sự kiện, nơi một số dịch vụ không truy cập cơ sở dữ liệu, nếu chúng phụ thuộc vào các dịch vụ mà có truy cập cơ sở dữ liệu, thì chúng trở thành một phần của sự kết nối tĩnh của quantum kiến trúc.

Figure 2-5. Even a distributed architecture such as broker-style event-driven architecture can be a single quantum

Tuy nhiên, còn những tình huống trong các kiến trúc phân tán mà không có các điểm kết nối chung thì sao? Hãy xem xét kiến trúc hướng sự kiện được minh họa trong Hình 2-6.

Các kiến trúc sư đã thiết kế hệ thống dựa trên sự kiện này với hai kho dữ liệu và không có sự phụ thuộc tĩnh giữa các tập dịch vụ. Lưu ý rằng mỗi khối lượng kiến trúc có thể hoạt động trong một hệ sinh thái giống như sản xuất. Nó có thể không tham gia vào tất cả các quy trình công việc yêu cầu của hệ thống, nhưng nó vẫn hoạt động thành công và vận hành—gửi yêu cầu và nhận chúng trong kiến trúc.

Đo lường mối liên kết tĩnh của một quantum kiến trúc đánh giá các sự phụ thuộc liên kết giữa các thành phần kiến trúc và hoạt động. Do đó, hệ điều hành, kho dữ liệu, trình môi giới tin nhắn, quản lý chứa và tất cả các sự phụ thuộc vận hành khác hình thành các điểm liên kết tĩnh của một quantum kiến trúc, sử dụng các hợp đồng chặt chẽ nhất có thể, các sự phụ thuộc vận hành (thêm thông tin về vai trò của các hợp đồng trong quantum kiến trúc sẽ có trong Chương 13).

Figure 2-6. An event-driven architecture with multiple quanta

Kiến trúc microservices có đặc điểm là các dịch vụ được tách rời cao, bao gồm cả các phụ thuộc về dữ liệu. Các kiến trúc sư trong những kiến trúc này ưa chuộng mức độ tách rời cao và chú ý không tạo ra các điểm kết nối giữa các dịch vụ, cho phép mỗi dịch vụ riêng lẻ hình thành các khối lượng riêng của nó, như được minh họa trong Hình 2-7.

Figure 2-7. Microservices may form their own quanta

Mỗi dịch vụ (được xem như một ngữ cảnh giới hạn) có thể có những đặc điểm kiến trúc riêng—một dịch vụ có thể có mức độ scalability hoặc bảo mật cao hơn dịch vụ khác. Mức độ chi tiết này trong việc xác định các đặc điểm kiến trúc là một trong những lợi thế của phong cách kiến trúc microservices. Mức độ tách rời cao cho phép các nhóm làm việc trên một dịch vụ di chuyển nhanh nhất có thể, mà không cần lo lắng về việc làm hỏng các phụ thuộc khác.

Tuy nhiên, nếu hệ thống gắn chặt với giao diện người dùng, kiến trúc sẽ hình thành một khối lượng kiến trúc duy nhất, như được minh họa trong Hình 2-8.

Figure 2-8. A tightly coupled user interface can reduce a microservices architecture quantum to one

Giao diện người dùng tạo ra các điểm kết nối giữa phía trước và phía sau, và hầu hết các giao diện người dùng sẽ không hoạt động nếu các phần của backend không khả dụng.

Hơn nữa, sẽ rất khó cho một kiến trúc sư để thiết kế các đặc điểm kiến trúc vận hành khác nhau (hiệu suất, quy mô, tính linh hoạt, độ tin cậy, v.v.) cho mỗi dịch vụ nếu chúng đều phải hợp tác với nhau trong một giao diện người dùng duy nhất (đặc biệt trong trường hợp các cuộc gọi đồng bộ, được đề cập trong “Liên kết năng động lượng tử”).

Các kiến trúc sư thiết kế giao diện người dùng sử dụng tính bất đồng bộ mà không tạo ra sự liên kết giữa phía trước và phía sau. Một xu hướng trong nhiều dự án vi dịch vụ là sử dụng một khung micro frontend cho các yếu tố giao diện người dùng trong kiến trúc vi dịch vụ. Trong một kiến trúc như vậy, các yếu tố giao diện người dùng tương tác thay mặt cho các dịch vụ được phát ra từ chính các dịch vụ đó. Bề mặt giao diện người dùng hoạt động như một bức tranh vẽ, nơi các yếu tố giao diện người dùng có thể xuất hiện, và cũng tạo điều kiện cho việc giao tiếp lỏng lẻo giữa các thành phần, thường sử dụng các sự kiện. Kiến trúc như vậy được minh họa trong Hình 2-9.

Figure 2-9. In a micro-frontend architecture, each service + user interface component forms an architecture quantum

Trong ví dụ này, bốn dịch vụ có màu sắc cùng với các micro-frontend tương ứng tạo thành các quanta kiến trúc: mỗi dịch vụ này có thể có những đặc điểm kiến trúc khác nhau.

Bất kỳ điểm kết nối nào trong một kiến trúc có thể tạo ra các điểm kết nối tĩnh từ quan điểm lượng tử. Hãy xem xét tác động của một cơ sở dữ liệu chung giữa hai hệ thống, như được minh họa trong Hình 2-10.

Sự kết nối tĩnh của một hệ thống cung cấp cái nhìn quý giá, ngay cả trong những hệ thống phức tạp liên quan đến kiến trúc tích hợp. Ngày càng nhiều, một kỹ thuật phổ biến của kiến trúc sư để hiểu kiến trúc kế thừa là tạo ra một sơ đồ lượng tử tĩnh về cách mọi thứ được "kết nối" với nhau, điều này giúp xác định những hệ thống nào sẽ bị ảnh hưởng bởi sự thay đổi và cung cấp một cách hiểu (và tiềm năng tách rời) kiến trúc.

Liên kết tĩnh chỉ là một nửa của các lực đang hoạt động trong kiến trúc phân tán. Nửa còn lại là liên kết động.

Figure 2-10. A shared database forms a coupling point between two systems, creating a single quantum

Dynamic Quantum Coupling

Phần cuối cùng của định nghĩa lượng kiến trúc liên quan đến việc kết hợp đồng bộ trong thời gian thực - nói cách khác, hành vi của các lượng kiến trúc khi chúng tương tác với nhau để hình thành các quy trình công việc trong một kiến trúc phân tán.

Bản chất của cách thức các dịch vụ gọi lẫn nhau tạo ra những quyết định đánh đổi khó khăn vì nó đại diện cho một không gian quyết định đa chiều, bị ảnh hưởng bởi ba lực lượng liên kết lẫn nhau:

Communication

Đề cập đến loại đồng bộ kết nối được sử dụng: đồng bộ hoặc bất đồng bộ.

Consistency

Mô tả liệu giao tiếp trong quy trình làm việc có yêu cầu tính nguyên tử hay có thể sử dụng tính nhất quán cuối cùng.

Coordination

Mô tả liệu quy trình làm việc có sử dụng bộ điều phối hay các dịch vụ giao tiếp thông qua hợp xướng.

Communication

Khi hai dịch vụ giao tiếp với nhau, một trong những câu hỏi cơ bản đối với một kiến trúc sư là liệu sự giao tiếp đó nên là đồng bộ hay bất đồng bộ.

Giao tiếp đồng bộ yêu cầu người yêu cầu phải chờ phản hồi từ người nhận, như đã thể hiện trong Hình 2-11.

Figure 2-11. A synchronous call waits for a result from the receiver

Dịch vụ gọi thực hiện một cuộc gọi (sử dụng một trong số các giao thức hỗ trợ các cuộc gọi đồng bộ, chẳng hạn như gRPC) và giữ chặn (không thực hiện xử lý thêm) cho đến khi người nhận trả về một giá trị (hoặc trạng thái chỉ ra sự thay đổi trạng thái hoặc điều kiện lỗi).

Giao tiếp bất đồng bộ xảy ra giữa hai dịch vụ khi người gọi gửi một tin nhắn đến người nhận (thường thông qua một cơ chế như hàng đợi tin nhắn) và, khi người gọi nhận được xác nhận rằng tin nhắn sẽ được xử lý, họ trở lại làm việc. Nếu yêu cầu cần một giá trị phản hồi, người nhận có thể sử dụng một hàng đợi phản hồi để (bất đồng bộ) thông báo cho người gọi về kết quả, như được minh họa trong Hình 2-12.

Figure 2-12. Asynchronous communication allows parallel processing

Người gọi gửi một tin nhắn tới hàng đợi tin nhắn và tiếp tục xử lý cho đến khi được thông báo bởi người nhận rằng thông tin yêu cầu đã có sẵn qua cuộc gọi trả lại. Thông thường, các kiến trúc sư sử dụng hàng đợi tin nhắn (được minh họa qua ống hình trụ màu x gray trong sơ đồ trên cùng của Hình 2-12) để thực hiện giao tiếp bất đồng bộ, nhưng hàng đợi là phổ biến và tạo ra tiếng ồn trong các sơ đồ, vì vậy nhiều kiến trúc sư không đưa chúng vào, như được hiển thị trong sơ đồ dưới. Và, tất nhiên, các kiến trúc sư có thể thực hiện giao tiếp bất đồng bộ mà không cần hàng đợi tin nhắn bằng cách sử dụng nhiều thư viện hoặc khung khác nhau. Mỗi loại sơ đồ đều ngụ ý thông điệp bất đồng bộ; sơ đồ thứ hai cung cấp rút gọn trực quan và ít chi tiết triển khai hơn.

Các kiến trúc sư phải xem xét các sự đánh đổi quan trọng khi chọn cách thức các dịch vụ sẽ giao tiếp. Những quyết định liên quan đến giao tiếp ảnh hưởng đến sự đồng bộ, xử lý lỗi, tính chất giao dịch, khả năng mở rộng và hiệu suất. Phần còn lại của cuốn sách này sẽ đi sâu vào nhiều vấn đề này.

Coordination

Sự phối hợp đề cập đến mức độ phối hợp mà quy trình làm việc được mô hình hóa bởi giao tiếp yêu cầu. Hai mẫu chung phổ biến cho microservices là tổ chức và biên đạo, mà chúng tôi sẽ mô tả trong Chương 11. Quy trình làm việc đơn giản - một dịch vụ đơn lẻ trả lời một yêu cầu - không cần sự xem xét đặc biệt từ khía cạnh này. Tuy nhiên, khi độ phức tạp của quy trình làm việc gia tăng, nhu cầu phối hợp càng lớn.

Ba yếu tố này - giao tiếp, tính nhất quán và sự phối hợp - đều ảnh hưởng đến quyết định quan trọng mà một kiến trúc sư phải đưa ra. Tuy nhiên, một cách quan trọng, các kiến trúc sư không thể đưa ra những lựa chọn này một cách độc lập; mỗi lựa chọn đều có ảnh hưởng lẫn nhau. Ví dụ, tính giao dịch dễ dàng hơn trong các kiến trúc đồng bộ có trung gian, trong khi các mức độ mở rộng cao hơn có thể đạt được với các hệ thống được phối hợp bất đồng bộ có tính nhất quán cuối cùng.

Suy nghĩ về những lực này như liên quan đến nhau tạo thành một không gian ba chiều, như được minh họa trong Hình 2-13.

Mỗi lực lượng trong giao tiếp dịch vụ xuất hiện như một chiều. Đối với một quyết định cụ thể, một kiến trúc sư có thể vẽ biểu đồ vị trí trong không gian đại diện cho sức mạnh của những lực lượng này.

Figure 2-13. The dimensions of dynamic quantum coupling

Khi một kiến trúc sư có thể xây dựng một hiểu biết rõ ràng về các lực tác động trong một tình huống nhất định, điều đó tạo ra các tiêu chí cho phân tích đánh đổi. Trong trường hợp của sự kết nối động, Bảng 2-1 cho thấy một khuôn khổ để xác định tên các mẫu cơ bản dựa trên tám tổ hợp có thể.

Table 2-1. The matrix of dimensional intersections for distributed architectures

Pattern name	Communication	Consistency	Coordination	Coupling
Trường ca sử thi	đồng bộ	nguyên tử	được tổ chức	rất cao
Trò Chơi Tag Điện Thoại	đồng bộ	nguyên tử	được biên đạo	cao
Huyền Thoại Cổ Tích	đồng bộ	cuối cùng	điều phối	cao
Cuộc Phiêu Lưu Du Hành Thời Gian	đồng bộ	cuối cùng	được dàn dựng	trung bình
Huyền ảo Tiểu thuyết Saga	không đồng bộ	nguyên tử	dàn dựng	cao
Truyện kinh dị	không đồng bộ	nguyên tử	dàn dựng	trung bình
Huyền thoại song song	bất đồng bộ	cuối cùng	được sắp xếp tài tình	thấp
"Huyền Thoại Tập"	không đồng bộ	cuối cùng	biên đạo	rất thấp

Để hiểu đầy đủ về ma trận này, chúng ta trước tiên phải xem xét từng chiều một cách riêng biệt. Do đó, các chương tiếp theo sẽ giúp bạn xây dựng bối cảnh để hiểu những đánh đổi riêng lẻ cho giao tiếp, tính nhất quán và phối hợp, sau đó gộp chúng lại với nhau trong Chương 12.

Trong các chương còn lại của Phần I, chúng tôi sẽ tập trung vào sự kết nối tĩnh và hiểu các khía cạnh khác nhau trong kiến trúc phân tán, bao gồm quyền sở hữu dữ liệu, tính giao dịch và độ granularity của dịch vụ. Trong Phần II, Ghép lại mọi thứ, chúng tôi tập trung vào sự kết nối động và hiểu các mẫu giao tiếp trong microservices.

Maintainability

Khả năng bảo trì liên quan đến sự dễ dàng trong việc thêm, thay đổi hoặc loại bỏ các tính năng, cũng như áp dụng các thay đổi nội bộ như các bản sửa lỗi bảo trì, nâng cấp framework, nâng cấp phần mềm của bên thứ ba, và nhiều hơn nữa. Giống như hầu hết các đặc điểm kiến trúc tổng hợp, khả năng bảo trì rất khó để định nghĩa một cách khách quan. Alexander von Zitzewitz, kiến trúc sư phần mềm và người sáng lập hello2morrow, đã viết một bài viết về một chỉ số mới nhằm định nghĩa khách quan mức độ khả năng bảo trì của một ứng dụng. Mặc dù chỉ số khả năng bảo trì của von Zitzewitz tương đối phức tạp và liên quan đến nhiều yếu tố, hình thức ban đầu của nó như sau:

Trong đó, ML là mức độ khả năng bảo trì của toàn bộ hệ thống (tỷ lệ phần trăm từ 0% đến 100%), k là tổng số thành phần logic trong hệ thống, và ci là mức độ kết nối cho bất kỳ thành phần nào, với sự chú ý đặc biệt đến mức độ kết nối chảy vào. Phương trình này về cơ bản chỉ ra rằng mức độ kết nối chảy vào giữa các thành phần càng cao thì mức độ khả năng bảo trì tổng thể của mã nguồn càng thấp.

Gác lại những toán học phức tạp, một số chỉ số điển hình được sử dụng để xác định khả năng bảo trì tương đối của một ứng dụng dựa trên các thành phần (các khối xây dựng kiến trúc của một ứng dụng) bao gồm những điều sau đây:

Component coupling

Mức độ và cách thức mà các thành phần biết về nhau.

Component cohesion

Mức độ và cách thức mà các hoạt động của một thành phần tương tác với nhau.

Cyclomatic complexity

Mức độ gián tiếp và lồng ghép tổng thể trong một thành phần

Component size

Số lượng các câu lệnh tổng hợp trong một thành phần

Technical versus domain partitioning

Các thành phần được sắp xếp theo cách sử dụng kỹ thuật hoặc theo mục đích miền - xem Phụ lục A

Trong ngữ cảnh của kiến trúc, chúng tôi định nghĩa một thành phần là một khối xây dựng kiến trúc của ứng dụng thực hiện một số loại chức năng kinh doanh hoặc hạ tầng, thường được thể hiện thông qua cấu trúc gói (Java), không gian tên (C#) hoặc tập hợp vật lý của các tệp (lớp) trong một cấu trúc thư mục nào đó. Ví dụ, thành phần Lịch sử Đơn hàng có thể được triển khai thông qua một tập hợp các tệp lớp nằm trong không gian tên app.business.order.history.

Các kiến trúc monolithic lớn thường có mức độ bảo trì thấp do việc phân chia chức năng thành các lớp kỹ thuật, sự liên kết chặt chẽ giữa các thành phần, và độ kết dính yếu của các thành phần từ góc độ miền. Ví dụ, hãy xem xét một yêu cầu mới trong một kiến trúc monolithic truyền thống có nhiều lớp để thêm ngày hết hạn cho các mục trong danh sách ước muốn của khách hàng (các mục trong danh sách có thể được mua sau này). Lưu ý trong Hình 3-4 rằng phạm vi thay đổi của yêu cầu mới là ở mức ứng dụng vì sự thay đổi được propogate đến tất cả các lớp trong ứng dụng.

Figure 3-4. With monolithic layered architectures, change is at an application level

Tùy thuộc vào cấu trúc đội ngũ, việc thực hiện thay đổi đơn giản này để thêm ngày hết hạn cho các mục trong danh sách ước nguyện trong một kiến trúc phân lớp nguyên khối có thể cần phối hợp của ít nhất ba đội.

• Một thành viên từ đội ngũ giao diện người dùng sẽ cần thiết để thêm trường hết hạn mới vào màn hình.

• Một thành viên từ nhóm backend sẽ cần thiết để thêm các quy tắc kinh doanh liên quan đến ngày hết hạn và thay đổi hợp đồng để thêm trường hết hạn mới.

• Một thành viên từ đội ngũ cơ sở dữ liệu sẽ cần thiết để thay đổi cấu trúc bảng để thêm cột thời hạn mới vào bảng Danh sách mong muốn.

Vì miền Danh sách mong muốn được phân bổ khắp toàn bộ kiến trúc, việc duy trì một miền hoặc tiểu miền cụ thể (chẳng hạn như Danh sách mong muốn) trở nên khó khăn hơn. Ngược lại, các kiến trúc mô-đun phân chia các miền và tiểu miền thành những đơn vị phần mềm nhỏ hơn, có thể triển khai riêng biệt, từ đó dễ dàng hơn trong việc sửa đổi một miền hoặc tiểu miền. Lưu ý rằng với kiến trúc dịch vụ phân tán, như được hiển thị trong Hình 3-5, phạm vi thay đổi của yêu cầu mới nằm ở cấp độ miền trong một dịch vụ miền cụ thể, giúp dễ dàng hơn trong việc cô lập đơn vị triển khai cụ thể cần thay đổi.

Chuyển sang tính mô-đun kiến trúc thậm chí nhiều hơn, chẳng hạn như kiến trúc microservices, như được minh họa trong Hình 3-6, đặt yêu cầu mới ở mức độ thay đổi chức năng, tách biệt sự thay đổi vào một dịch vụ cụ thể chịu trách nhiệm cho chức năng danh sách mong muốn.

Figure 3-5. With service-based architectures, change is at a domain level

Figure 3-6. With microservices architectures, change is at a function level

Ba quá trình tiến tới tính mô-đun này cho thấy rằng khi mức độ tính mô-đun của kiến trúc tăng lên, khả năng bảo trì cũng tăng theo, khiến việc thêm, thay đổi hoặc loại bỏ chức năng trở nên dễ dàng hơn.

Testability

Khả năng kiểm tra được định nghĩa là mức độ dễ dàng trong việc kiểm tra (thường được thực hiện thông qua các bài kiểm tra tự động) cũng như độ hoàn chỉnh của việc kiểm tra. Khả năng kiểm tra là một thành phần thiết yếu cho sự linh hoạt trong kiến trúc. Các kiểu kiến trúc lớn như kiến trúc phân lớp hỗ trợ mức độ khả năng kiểm tra (và do đó là tính linh hoạt) tương đối thấp do khó khăn trong việc đạt được kiểm tra hồi quy đầy đủ và hoàn chỉnh cho tất cả các tính năng trong đơn vị triển khai lớn. Ngay cả khi một ứng dụng monolithic có một bộ kiểm tra hồi quy đầy đủ, hãy tưởng tượng sự thất vọng khi phải thực hiện hàng trăm hoặc thậm chí hàng nghìn bài kiểm tra đơn vị cho một thay đổi mã đơn giản. Không chỉ mất nhiều thời gian để thực hiện tất cả các bài kiểm tra, mà nhà phát triển tội nghiệp sẽ phải đau đầu nghiên cứu lý do tại sao hàng chục bài kiểm tra thất bại khi thực tế các bài kiểm tra thất bại đó không liên quan gì đến thay đổi.

Tính mô-đun kiến trúc—việc chia nhỏ các ứng dụng thành các đơn vị triển khai nhỏ hơn—giảm đáng kể phạm vi kiểm tra tổng thể cho các thay đổi được thực hiện đối với một dịch vụ, cho phép độ hoàn thiện của việc kiểm tra tốt hơn cũng như dễ dàng hơn trong việc kiểm tra. Không chỉ mô-đun hóa dẫn đến các bộ kiểm tra nhỏ hơn, nhắm mục tiêu hơn, mà việc duy trì các bài kiểm tra đơn vị cũng trở nên dễ dàng hơn.

Trong khi tính mô-đun kiến trúc thường cải thiện khả năng kiểm thử, nó đôi khi có thể dẫn đến những vấn đề tương tự như những vấn đề tồn tại với các ứng dụng đơn thể, triển khai đơn. Ví dụ, hãy xem xét một ứng dụng được chia thành ba đơn vị triển khai nhỏ tự chứa (dịch vụ), như được minh họa trong Hình 3-7.

Việc thay đổi Dịch vụ A chỉ giới hạn phạm vi kiểm thử cho dịch vụ đó, vì Dịch vụ B và Dịch vụ C không liên kết với Dịch vụ A. Tuy nhiên, khi sự giao tiếp giữa các dịch vụ này tăng lên, như được thể hiện ở cuối Hình 3-7, khả năng kiểm thử giảm nhanh chóng vì phạm vi kiểm thử cho một thay đổi đối với Dịch vụ A hiện bao gồm cả Dịch vụ B và Dịch vụ C, do đó ảnh hưởng đến cả sự dễ dàng trong kiểm thử và độ đầy đủ của kiểm thử.

Figure 3-7. Testing scope is increased as services communicate with one another

Deployability

Khả năng triển khai không chỉ liên quan đến sự dễ dàng trong quá trình triển khai – mà còn liên quan đến tần suất triển khai và mức độ rủi ro tổng thể của việc triển khai. Để hỗ trợ sự linh hoạt và phản ứng nhanh với sự thay đổi, các ứng dụng phải hỗ trợ cả ba yếu tố này. Triển khai phần mềm mỗi hai tuần (hoặc thường xuyên hơn) không chỉ làm gia tăng rủi ro tổng thể trong việc triển khai (do việc nhóm nhiều thay đổi lại với nhau), mà trong hầu hết các trường hợp, còn làm chậm trễ không cần thiết các tính năng mới hoặc sửa lỗi đã sẵn sàng để được phát hành cho khách hàng. Tất nhiên, tần suất triển khai phải được cân bằng với khả năng của khách hàng (hoặc người dùng cuối) để có thể tiếp nhận thay đổi nhanh chóng.

Kiến trúc monolithic thường hỗ trợ mức độ triển khai thấp do lượng thủ tục cần thiết trong việc triển khai ứng dụng (chẳng hạn như đóng băng mã, triển khai giả, và những việc tương tự), rủi ro cao rằng điều gì đó khác có thể gặp trục trặc khi các tính năng mới hoặc sửa lỗi được triển khai, và thời gian dài giữa các lần triển khai (tuần đến tháng). Các ứng dụng có một mức độ modularity kiến trúc nhất định theo các đơn vị phần mềm được triển khai riêng lẻ có ít thủ tục triển khai hơn, ít rủi ro khi triển khai, và có thể được triển khai thường xuyên hơn so với một ứng dụng monolithic lớn, đơn lẻ.

Cũng giống như khả năng kiểm tra, khả năng triển khai cũng bị ảnh hưởng tiêu cực khi các dịch vụ trở nên nhỏ hơn và giao tiếp nhiều hơn với nhau để hoàn thành một giao dịch kinh doanh. Rủi ro triển khai tăng lên, và việc triển khai một thay đổi đơn giản trở nên khó khăn hơn vì sợ làm hỏng các dịch vụ khác. Để trích dẫn kiến trúc sư phần mềm Matt Stine trong bài viết của ông về việc phối hợp các microservices:

Nếu các microservices của bạn phải được triển khai như một bộ hoàn chỉnh theo thứ tự cụ thể, xin hãy đưa chúng trở lại thành một monolith và tiết kiệm cho bản thân một số đau đớn.

Kịch bản này dẫn đến cái gọi là "quả bóng lớn của sự hỗn độn phân tán," nơi rất ít (nếu không muốn nói là không có) lợi ích của tính mô-đun kiến trúc được hiện thực hóa.

Scalability

Khả năng mở rộng được định nghĩa là khả năng của một hệ thống duy trì phản hồi khi tải người dùng tăng dần theo thời gian. Liên quan đến khả năng mở rộng là tính đàn hồi, được định nghĩa là khả năng của một hệ thống duy trì phản hồi trong các đỉnh tải người dùng cao và bất ngờ. Hình 3-8 minh họa sự khác biệt giữa khả năng mở rộng và tính đàn hồi.

Figure 3-8. Scalability is different from elasticity

Trong khi cả hai đặc điểm kiến trúc này đều bao gồm khả năng phản hồi như một chức năng của số lượng yêu cầu đồng thời (hoặc người dùng trong hệ thống), chúng được xử lý khác nhau từ góc độ kiến trúc và triển khai. Khả năng mở rộng thường xảy ra trong một khoảng thời gian dài hơn như một chức năng của sự tăng trưởng bình thường của công ty, trong khi tính co giãn là phản ứng ngay lập tức đối với một đợt tăng tải người dùng.

Một ví dụ tuyệt vời để làm rõ sự khác biệt là hệ thống bán vé concert. Giữa các sự kiện concert lớn, thường có một tải người dùng đồng thời tương đối nhẹ. Tuy nhiên, ngay khi vé bắt đầu được bán cho một buổi hòa nhạc nổi tiếng, tải người dùng đồng thời sẽ tăng vọt một cách đáng kể. Hệ thống có thể từ 20 người dùng đồng thời tăng lên 3,000 người sử dụng chỉ trong vài giây. Để duy trì tính phản hồi, hệ thống phải có khả năng xử lý các đỉnh cao trong tải người dùng, và cũng phải có khả năng khởi động ngay lập tức các dịch vụ bổ sung để xử lý sự gia tăng lưu lượng. Tính linh hoạt phụ thuộc vào việc các dịch vụ có thời gian khởi động trung bình rất nhỏ (MTTS), điều này đạt được bằng cách kiến trúc hệ thống với các dịch vụ rất nhỏ, tinh vi. Với một giải pháp kiến trúc phù hợp, MTTS (và do đó tính linh hoạt) có thể được quản lý thêm thông qua các kỹ thuật thiết kế như các nền tảng nhẹ nhỏ gọn và môi trường thực thi.

Mặc dù cả khả năng mở rộng và tính linh hoạt đều cải thiện với các dịch vụ có độ chi tiết cao hơn, nhưng tính linh hoạt chủ yếu là chức năng của độ chi tiết (kích thước của một đơn vị triển khai), trong khi khả năng mở rộng chủ yếu là chức năng của tính mô-đun (cách tách rời các ứng dụng thành các đơn vị triển khai riêng biệt). Hãy xem xét các kiểu kiến trúc truyền thống lớp, kiến trúc dựa trên dịch vụ và kiến trúc microservices cùng với các đánh giá sao tương ứng cho khả năng mở rộng và tính linh hoạt của chúng, như được minh họa trong Hình 3-9 (các chi tiết về các kiểu kiến trúc này và các đánh giá sao tương ứng của chúng có thể được tìm thấy trong cuốn sách trước của chúng tôi, Cơ bản về Kiến trúc Phần mềm. Lưu ý rằng một sao có nghĩa là khả năng này không được hỗ trợ tốt bởi kiểu kiến trúc, trong khi năm sao có nghĩa là khả năng đó là một tính năng chính của kiểu kiến trúc và được hỗ trợ tốt.

Lưu ý rằng khả năng mở rộng và tính đàn hồi tương đối thấp với kiến trúc phân layered đơn khối. Các kiến trúc phân layered đơn khối lớn vừa khó vừa tốn kém để mở rộng vì tất cả các chức năng của ứng dụng phải mở rộng ở cùng một mức độ (khả năng mở rộng ở cấp ứng dụng và thời gian khởi động trung bình kém). Điều này có thể trở nên đặc biệt tốn kém trong các hạ tầng dựa trên đám mây. Tuy nhiên, với kiến trúc dựa trên dịch vụ, lưu ý rằng khả năng mở rộng cải thiện, nhưng không nhiều như tính đàn hồi. Điều này là do các dịch vụ miền trong kiến trúc dựa trên dịch vụ có kích thước lớn và thường chứa toàn bộ miền trong một đơn vị triển khai (chẳng hạn như xử lý đơn hàng hoặc quản lý kho), và thường có thời gian khởi động trung bình (MTTS) quá lâu để phản ứng nhanh với nhu cầu tức thì về tính đàn hồi do kích thước lớn của chúng (khả năng mở rộng ở cấp miền và MTTS hợp lý). Lưu ý rằng với vi dịch vụ, cả khả năng mở rộng và tính đàn hồi đều được tối đa hóa nhờ vào tính chất nhỏ, một mục đích, và chi tiết của mỗi dịch vụ được triển khai riêng lẻ (khả năng mở rộng ở cấp chức năng và MTTS xuất sắc).

Như khả năng kiểm tra và khả năng triển khai, càng nhiều dịch vụ giao tiếp với nhau để hoàn thành một giao dịch kinh doanh đơn lẻ, thì tác động tiêu cực đến khả năng mở rộng và tính đàn hồi càng lớn. Vì lý do này, điều quan trọng là giảm thiểu giao tiếp đồng bộ giữa các dịch vụ khi yêu cầu mức độ khả năng mở rộng và tính đàn hồi cao.

Figure 3-9. Scalability and elasticity improve with modularity

Availability/Fault Tolerance

Giống như nhiều đặc điểm kiến trúc khác, tính chịu lỗi có những định nghĩa khác nhau. Trong bối cảnh của tính mô-đun kiến trúc, chúng tôi định nghĩa tính chịu lỗi là khả năng của một số bộ phận của hệ thống vẫn giữ được khả năng phản hồi và sẵn có khi các bộ phận khác của hệ thống gặp lỗi. Ví dụ, nếu xảy ra một lỗi nghiêm trọng (như tình huống hết bộ nhớ) trong phần xử lý thanh toán của một ứng dụng bán lẻ, người dùng của hệ thống vẫn nên có khả năng tìm kiếm các mặt hàng và đặt hàng, mặc dù việc xử lý thanh toán không khả dụng.

Tất cả các hệ thống đơn khối đều gặp phải mức độ chịu lỗi thấp. Mặc dù khả năng chịu lỗi có thể được giảm bớt trong một hệ thống đơn khối bằng cách có nhiều phiên bản của toàn bộ ứng dụng được cân bằng tải, nhưng kỹ thuật này vừa tốn kém vừa không hiệu quả. Nếu lỗi xuất phát từ một lỗi lập trình, lỗi đó sẽ tồn tại trong cả hai phiên bản, do đó có khả năng làm sập cả hai phiên bản.

Tính mô-đun kiến trúc là cần thiết để đạt được khả năng chịu lỗi ở cấp độ miền và cấp độ chức năng trong một hệ thống. Bằng cách tách rời hệ thống thành nhiều đơn vị triển khai, sự cố nghiêm trọng chỉ giới hạn trong đơn vị triển khai đó, do đó cho phép phần còn lại của hệ thống hoạt động bình thường. Tuy nhiên, có một điều cần lưu ý: nếu các dịch vụ khác phụ thuộc đồng bộ vào một dịch vụ đang gặp lỗi, khả năng chịu lỗi không được đảm bảo. Đây là một trong những lý do mà giao tiếp không đồng bộ giữa các dịch vụ là rất quan trọng để duy trì một mức độ khả năng chịu lỗi tốt trong một hệ thống phân tán.

Afferent and Efferent Coupling

Vào năm 1979, Edward Yourdon và Larry Constantine đã xuất bản cuốn sách Thiết kế có cấu trúc: Những nguyên tắc cơ bản của một ngành thiết kế chương trình và hệ thống máy tính (Yourdon), định nghĩa nhiều khái niệm cốt lõi, bao gồm các chỉ số coupling vào (afferent) và coupling ra (efferent). Coupling vào đo lường số lượng kết nối đến một đối tượng mã (thành phần, lớp, hàm, v.v.). Coupling ra đo lường các kết nối ra ngoài đến các đối tượng mã khác.

Lưu ý giá trị của chỉ hai biện pháp này khi thay đổi cấu trúc của một hệ thống. Ví dụ, khi phân tách một kiến trúc monolith thành một kiến trúc phân tán, kiến trúc sư sẽ tìm thấy các lớp chia sẻ như Địa chỉ. Khi xây dựng một monolith, việc tái sử dụng các khái niệm cốt lõi như Địa chỉ là điều phổ biến và được khuyến khích cho các nhà phát triển, nhưng khi tách rời monolith, giờ đây kiến trúc sư phải xác định có bao nhiêu phần khác của hệ thống sử dụng tài sản chia sẻ này.

Hầu như mọi nền tảng đều có các công cụ cho phép các kiến trúc sư phân tích các đặc điểm liên kết của mã để hỗ trợ trong việc tái cấu trúc, di chuyển hoặc hiểu biết về một mã nguồn. Nhiều công cụ tồn tại cho các nền tảng khác nhau cung cấp cái nhìn ma trận về các mối quan hệ giữa các lớp và/hoặc thành phần, như được minh họa trong Hình 4-2.

Trong ví dụ này, plug-in Eclipse cung cấp một hình ảnh trực quan của đầu ra của JDepend, bao gồm phân tích sự kết nối theo gói, cùng với một số chỉ số tổng hợp được làm nổi bật trong phần tiếp theo.

Figure 4-2. JDepend in Eclipse analysis view of coupling relationships

Abstractness and Instability

Robert Martin, một nhân vật nổi tiếng trong lĩnh vực kiến trúc phần mềm, đã tạo ra một số chỉ số dẫn xuất cho một cuốn sách C++ vào cuối những năm 1990, có thể áp dụng cho bất kỳ ngôn ngữ lập trình hướng đối tượng nào. Các chỉ số này—độ trừu tượng và độ không ổn định—đo lường sự cân bằng của các đặc điểm nội tại của một mã nguồn.

Độ trừu tượng là tỷ lệ giữa các đối tượng trừu tượng (các lớp trừu tượng, giao diện, v.v.) và các đối tượng cụ thể (các lớp triển khai). Nó đại diện cho một thước đo giữa trừu tượng và triển khai. Các yếu tố trừu tượng là các tính năng của một cơ sở mã cho phép các lập trình viên hiểu chức năng tổng thể tốt hơn. Ví dụ, một cơ sở mã chỉ bao gồm một phương thức main() và 10.000 dòng mã sẽ có điểm gần bằng không trong chỉ số này và sẽ khá khó hiểu.

Công thức cho tính trừu tượng xuất hiện trong Phương trình 4-1.

Trong phương trình, m a đại diện cho các yếu tố trừu tượng (giao diện hoặc lớp trừu tượng) trong mã nguồn, và m c đại diện cho các yếu tố cụ thể. Các kiến trúc sư tính toán độ trừu tượng bằng cách tính tỷ lệ giữa tổng của các đối tượng trừu tượng và tổng của các đối tượng cụ thể.

Một chỉ số suy diễn khác, độ không ổn định, là tỷ lệ giữa sự liên kết ra (efferent coupling) và tổng của cả sự liên kết ra và sự liên kết vào (afferent coupling), được trình bày trong Phương trình 4-2.

Trong phương trình, C e đại diện cho sự kết nối hướng ra (hoặc hướng đi ra), và C a đại diện cho sự kết nối hướng vào (hoặc hướng đi vào).

Chỉ số không ổn định xác định sự biến động của một mã nguồn. Một mã nguồn thể hiện mức độ không ổn định cao sẽ dễ bị hỏng hơn khi có sự thay đổi do sự liên kết chặt chẽ. Xem xét hai kịch bản, mỗi kịch bản có C a = 2. Đối với kịch bản đầu tiên, C e = 0, cho ra chỉ số không ổn định bằng không. Trong kịch bản khác, C e = 3, cho ra chỉ số không ổn định là 3/5. Do đó, chỉ số không ổn định cho một thành phần phản ánh số lượng thay đổi tiềm năng có thể xảy ra khi có sự thay đổi ở các thành phần liên quan. Một thành phần có giá trị không ổn định gần bằng một là rất không ổn định, còn giá trị gần bằng không có thể ổn định hoặc cứng nhắc: nó ổn định nếu mô-đun hoặc thành phần chứa chủ yếu các yếu tố trừu tượng, và cứng nhắc nếu nó chủ yếu bao gồm các yếu tố cụ thể. Tuy nhiên, sự đánh đổi cho độ ổn định cao là thiếu khả năng tái sử dụng—nếu mỗi thành phần đều độc lập, thì sự trùng lặp là điều có khả năng xảy ra.

Một thành phần có giá trị I gần với 1, chúng ta có thể đồng ý, là rất không ổn định. Tuy nhiên, một thành phần có giá trị I gần với 0 có thể là ổn định hoặc cứng. Tuy nhiên, nếu nó chủ yếu chứa các yếu tố bê tông, thì nó là cứng.

Do đó, nói chung, điều quan trọng là xem xét giá trị của I và A cùng nhau thay vì tách rời. Vì vậy, lý do để xem xét chuỗi chính được trình bày trên trang tiếp theo.

Distance from the Main Sequence

Một trong số ít các chỉ số toàn diện mà các kiến trúc sư có cho cấu trúc kiến trúc là khoảng cách từ chuỗi chính, một chỉ số được suy ra dựa trên sự không ổn định và tính trừu tượng, được trình bày trong Phương trình 4-3.

Trong phương trình, A = trừu tượng và I = bất ổn.

Métric khoảng cách từ chuỗi chính tưởng tượng mối quan hệ lý tưởng giữa tính trừu tượng và sự không ổn định; các thành phần nằm gần đường lý tưởng này thể hiện sự kết hợp lành mạnh của hai mối quan tâm đối lập này. Ví dụ, việc vẽ đồ thị một thành phần cụ thể cho phép các nhà phát triển tính toán métric khoảng cách từ chuỗi chính, được minh họa trong Hình 4-3.

Figure 4-3. Normalized distance from the main sequence for a particular component

Các nhà phát triển vẽ đồ thị thành phần ứng viên, sau đó đo khoảng cách từ đường lý tưởng. Càng gần đến đường, thành phần càng được cân bằng tốt. Những thành phần rơi quá xa vào góc trên bên phải sẽ rơi vào cái mà các kiến trúc sư gọi là vùng vô dụng: mã quá trừu tượng trở nên khó sử dụng. Ngược lại, mã rơi vào góc dưới bên trái sẽ rơi vào vùng đau đớn: mã có quá nhiều triển khai và không đủ trừu tượng trở nên giòn và khó bảo trì, như được minh họa trong Hình 4-4.

Các công cụ tồn tại trên nhiều nền tảng để cung cấp các biện pháp này, giúp các kiến trúc sư khi phân tích mã nguồn do sự không quen thuộc, di chuyển hoặc đánh giá nợ kỹ thuật.

Metric "distance-from-the-main-sequence" cho các kiến trúc sư đang tìm cách cấu trúc lại ứng dụng có ý nghĩa gì? Giống như trong các dự án xây dựng, việc di chuyển một cấu trúc lớn có nền tảng kém sẽ mang lại những rủi ro. Tương tự, nếu một kiến trúc sư mơ ước cấu trúc lại một ứng dụng, việc cải thiện cấu trúc bên trong sẽ giúp dễ dàng hơn trong việc di chuyển thực thể đó.

Figure 4-4. Zones of uselessness and pain

Chỉ số này cũng cung cấp một manh mối tốt về sự cân bằng của cấu trúc nội bộ. Nếu một kiến trúc sư đánh giá một mã nguồn mà nhiều thành phần rơi vào các khu vực vô dụng hoặc đau đớn, có lẽ không đáng để dành thời gian cố gắng cải thiện cấu trúc nội bộ đến mức có thể được sửa chữa.

Theo sơ đồ luồng trong Hình 4-1, một khi kiến trúc sư quyết định rằng mã nguồn có thể được phân tách, bước tiếp theo là xác định cách tiếp cận để phân tách ứng dụng. Các phần sau đây mô tả hai cách tiếp cận để phân tách một ứng dụng: phân tách dựa trên thành phần và phân tách chiến thuật.

Trade-Offs

Tách nhánh chiến thuật là một phương pháp thay thế khả thi cho cách tiếp cận phân tích chính thức hơn, thích hợp nhất cho các mã nguồn có ít hoặc không có cấu trúc nội bộ. Giống như tất cả các thực hành trong kiến trúc, nó có những nhược điểm của riêng mình.

Benefits

• Các nhóm có thể bắt đầu làm việc ngay lập tức mà hầu như không cần phân tích trước.

• Các lập trình viên cảm thấy việc xóa mã dễ hơn là trích xuất nó. Việc trích xuất mã từ một cơ sở mã hỗn độn gặp khó khăn do sự liên kết chặt chẽ, trong khi mã không cần thiết có thể được xác minh bằng biên dịch hoặc thử nghiệm đơn giản.

Shortcomings

• Các dịch vụ thu được có thể vẫn chứa một lượng lớn mã chủ yếu là tiềm ẩn còn sót lại từ kiến trúc đơn thể.

• Nếu các nhà phát triển không thực hiện thêm nỗ lực, mã bên trong các dịch vụ mới được tạo ra sẽ không tốt hơn mã hỗn loạn từ monolith—chỉ là có ít hơn.

• Sự không nhất quán có thể xảy ra giữa tên của mã chia sẻ và các tệp thành phần chia sẻ, dẫn đến khó khăn trong việc xác định mã chung và giữ cho nó nhất quán.

Tên của mẫu này rất hợp lý (như tất cả các tên mẫu tốt nên có) - nó cung cấp một cách tiếp cận chiến thuật hơn là chiến lược để cấu trúc lại các kiến trúc, cho phép các đội nhóm nhanh chóng di chuyển các hệ thống quan trọng hoặc thiết yếu lên thế hệ tiếp theo (mặc dù theo một cách không có cấu trúc).

Pattern Description

Vì các dịch vụ được xây dựng từ các thành phần, việc xác định không chỉ các thành phần trong một ứng dụng mà còn phải định kích thước chính xác cho chúng là rất quan trọng. Mẫu này được sử dụng để xác định các thành phần có kích thước quá lớn (thực hiện quá nhiều) hoặc quá nhỏ (không thực hiện đủ). Các thành phần quá lớn so với các thành phần khác thường liên kết chặt chẽ hơn với các thành phần khác, khó tách ra thành các dịch vụ riêng biệt và dẫn đến một kiến trúc ít mô-đun hơn.

Thật không may, việc xác định kích thước của một thành phần là khá khó khăn. Số lượng tệp nguồn, lớp và tổng số dòng mã không phải là những chỉ số tốt vì mỗi lập trình viên thiết kế lớp, phương thức và hàm theo cách riêng của họ. Một chỉ số mà chúng tôi thấy hữu ích cho việc đo kích thước thành phần là tính tổng số câu lệnh trong một thành phần nhất định (tổng số câu lệnh trong tất cả các tệp nguồn nằm trong một không gian tên hoặc thư mục). Một câu lệnh là một hành động hoàn chỉnh duy nhất được thực hiện trong mã nguồn, thường kết thúc bằng một ký tự đặc biệt (như dấu chấm phẩy trong các ngôn ngữ như Java, C, C++, C#, Go và JavaScript; hoặc một dòng mới trong các ngôn ngữ như F#, Python và Ruby). Mặc dù không phải là một chỉ số hoàn hảo, ít nhất nó là một chỉ số tốt về mức độ mà thành phần đang thực hiện và độ phức tạp của thành phần đó.

Việc có kích thước thành phần tương đối đồng nhất trong một ứng dụng là rất quan trọng. Nói chung, kích thước của các thành phần trong một ứng dụng nên rơi vào khoảng từ một đến hai độ lệch chuẩn so với kích thước thành phần trung bình (hoặc mean). Bên cạnh đó, tỷ lệ mã mà mỗi thành phần đại diện nên được phân bổ khá đều giữa các thành phần của ứng dụng và không nên thay đổi đáng kể.

Trong khi nhiều công cụ phân tích mã tĩnh có thể cho thấy số lượng câu lệnh trong một tệp nguồn, nhiều công cụ trong số đó không tổng hợp số câu lệnh tổng cộng theo thành phần. Vì lý do này, kiến trúc sư thường phải thực hiện xử lý sau bằng tay hoặc tự động để tổng hợp số câu lệnh tổng cộng theo thành phần và sau đó tính toán tỷ lệ phần trăm mã mà thành phần đó đại diện.

Bất kể công cụ hoặc thuật toán nào được sử dụng, thông tin và các chỉ số quan trọng cần thu thập và tính toán cho mẫu này được trình bày trong Bảng 5-1 và được định nghĩa trong danh sách sau.

Component name

Một tên mô tả và định danh của thành phần cần phải nhất quán trong toàn bộ các sơ đồ ứng dụng và tài liệu. Tên thành phần nên rõ ràng đủ để có thể tự mô tả. Ví dụ, thành phần Lịch sử Thanh toán được hiển thị trong Bảng 5-1 rõ ràng là một thành phần chứa các tệp mã nguồn được sử dụng để quản lý lịch sử thanh toán của khách hàng. Nếu vai trò và trách nhiệm cụ thể của thành phần không thể xác định ngay lập tức, hãy cân nhắc thay đổi thành phần (và có thể cả không gian tên tương ứng) thành một cái tên mô tả hơn. Ví dụ, một thành phần được gọi là Quản lý Vé để lại quá nhiều câu hỏi chưa có lời giải thích về vai trò và trách nhiệm của nó trong hệ thống, và nên được đổi tên để mô tả rõ hơn vai trò của nó.

Component namespace

Sự xác định vật lý (hoặc logic) của thành phần đại diện cho nơi các tệp mã nguồn thực hiện thành phần đó được nhóm và lưu trữ. Nhận dạng này thường được thể hiện thông qua một không gian tên, cấu trúc gói (Java) hoặc cấu trúc thư mục. Khi một cấu trúc thư mục được sử dụng để chỉ định thành phần, chúng ta thường chuyển đổi ký tự phân cách tệp thành dấu chấm (.) và tạo ra một không gian tên logic tương ứng. Ví dụ, không gian tên của thành phần cho các tệp mã nguồn trong cấu trúc thư mục ss/customer/notification sẽ có giá trị không gian tên ss.customer.notification. Một số ngôn ngữ yêu cầu rằng không gian tên phải khớp với cấu trúc thư mục (chẳng hạn như Java với một gói), trong khi các ngôn ngữ khác (chẳng hạn như C# với một không gian tên) không thực thi ràng buộc này. Dù bất kỳ nhận diện không gian tên nào được sử dụng, hãy đảm bảo loại nhận diện này nhất quán giữa tất cả các thành phần trong ứng dụng.

Percent

Kích thước tương đối của thành phần dựa trên tỷ lệ phần trăm của mã nguồn tổng thể chứa thành phần đó. Đo lường phần trăm này hữu ích trong việc xác định các thành phần có vẻ quá lớn hoặc quá nhỏ trong ứng dụng tổng thể. Đo lường này được tính bằng cách lấy tổng số câu lệnh trong các tệp mã nguồn đại diện cho thành phần đó và chia con số đó cho tổng số câu lệnh trong toàn bộ mã nguồn của ứng dụng. Ví dụ, giá trị phần trăm 5 cho thành phần ss.billing.payment trong Bảng 5-1 có nghĩa là thành phần này chiếm 5% của toàn bộ mã nguồn.

Statements

Tổng số câu lệnh mã nguồn trong tất cả các tệp nguồn chứa trong thành phần đó. Chỉ tiêu này hữu ích không chỉ để xác định kích thước tương đối của các thành phần trong một ứng dụng, mà còn để xác định độ phức tạp tổng thể của thành phần. Ví dụ, một thành phần đơn giản có mục đích duy nhất mang tên Danh sách mong muốn của Khách hàng có thể có tổng cộng 12.000 câu lệnh, cho thấy rằng việc xử lý các mục trong danh sách mong muốn có thể phức tạp hơn những gì nó thể hiện. Chỉ tiêu này cũng cần thiết để tính toán chỉ tiêu phần trăm đã được mô tả trước đó.

Files

Tổng số tệp mã nguồn (chẳng hạn như lớp, giao diện, kiểu, và những thứ khác) có trong thành phần. Trong khi chỉ số này ít liên quan đến kích thước của một thành phần, nó cung cấp thông tin bổ sung về thành phần từ góc độ cấu trúc lớp. Ví dụ, một thành phần có 18,409 câu lệnh và chỉ có 2 tệp là một ứng cử viên tốt để tái cấu trúc thành các lớp nhỏ hơn, có ngữ cảnh hơn.

Khi điều chỉnh kích thước một thành phần lớn, chúng tôi khuyên bạn nên sử dụng phương pháp phân rã chức năng hoặc phương pháp định hướng miền để xác định các miền phụ có thể tồn tại trong thành phần lớn đó. Ví dụ, giả sử ứng dụng Sysops Squad có một thành phần Ticket Trouble chứa 22% mã nguồn chịu trách nhiệm cho việc tạo, phân công, định tuyến và hoàn thành vé. Trong trường hợp này, có thể hợp lý khi chia thành phần Ticket Trouble duy nhất thành bốn thành phần riêng biệt (Tạo Vé, Phân Công Vé, Định Tuyến Vé và Hoàn Thành Vé), giảm tỷ lệ phần trăm mã mà mỗi thành phần đại diện, từ đó tạo ra một ứng dụng mô-đun hơn. Nếu không có miền phụ rõ ràng nào tồn tại trong một thành phần lớn, thì hãy giữ nguyên thành phần đó.

Fitness Functions for Governance

Khi mẫu phân rã này đã được áp dụng và các thành phần đã được xác định và kích thước đúng, điều quan trọng là áp dụng một hình thức quản trị tự động để xác định các thành phần mới và đảm bảo rằng các thành phần không trở nên quá lớn trong quá trình bảo trì ứng dụng bình thường, từ đó tạo ra các phụ thuộc không mong muốn hoặc không dự kiến. Các hàm đánh giá tự động toàn diện có thể được kích hoạt trong quá trình triển khai để cảnh báo kiến trúc sư nếu các ràng buộc được chỉ định bị vi phạm (chẳng hạn như số liệu phần trăm đã được thảo luận trước đó hoặc việc sử dụng độ lệch chuẩn để xác định các trường hợp ngoại lệ).

Các hàm tính toán fitness có thể được triển khai thông qua mã viết tùy chỉnh hoặc thông qua việc sử dụng các công cụ mã nguồn mở hoặc COTS như một phần của quy trình CI/CD. Một số hàm tính toán tự động có thể được sử dụng để giúp quản lý mẫu phân rã này như sau.

# Get prior component namespaces that are stored in a datastore LIST prior_list = read_from_datastore() # Walk the directory structure, creating namespaces for each complete path LIST current_list = identify_components(root_directory) # Send an alert if new or removed components are identified LIST added_list = find_added(current_list, prior_list) LIST removed_list = find_removed(current_list, prior_list) IF added_list NOT EMPTY { add_to_datastore(added_list) send_alert(added_list) } IF removed_list NOT EMPTY { remove_from_datastore(removed_list) send_alert(removed_list) }

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Walk through all of the source code to accumulate total statements total_statements = accumulate_statements(root_directory) # Walk through the source code for each component, accumulating statements # and calculating the percentage of code each component represents. Send # an alert if greater than 10% FOREACH component IN component_list { component_statements = accumulate_statements(component) percent = component_statements / total_statements IF percent > .10 { send_alert(component, percent) } }

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Walk through all of the source code to accumulate total statements and number # of statements per component SET total_statements TO 0 MAP component_size_map FOREACH component IN component_list { num_statements = accumulate_statements(component) ADD num_statements TO total_statements ADD component,num_statements TO component_size_map } # Calculate the standard deviation SET square_diff_sum TO 0 num_components = get_num_entries(component_list) mean = total_statements / num_components FOREACH component,size IN component_size_map { diff = size - mean ADD square(diff) TO square_diff_sum } std_dev = square_root(square_diff_sum / (num_components - 1)) # For each component calculate the number of standard deviations from the # mean. Send an alert if greater than 3 FOREACH component,size IN component_size_map { diff_from_mean = absolute_value(size - mean); num_std_devs = diff_from_mean / std_dev IF num_std_devs > 3 { send_alert(component, num_std_devs) } }

Sysops Squad Saga: Sizing Components

Thứ Ba, ngày 2 tháng 11, 09:12

Sau cuộc thảo luận với Logan (kiến trúc sư trưởng) về các mẫu phân hoạch dựa trên thành phần, Addison quyết định áp dụng mẫu Nhận diện và Định kích thước Các thành phần để xác định tất cả các thành phần trong ứng dụng ticketing của Đội Sysops và tính toán kích thước của mỗi thành phần dựa trên tổng số câu lệnh trong mỗi thành phần.

Addison đã thu thập tất cả thông tin cần thiết về các thành phần và đưa thông tin này vào Bảng 5-2, tính toán phần trăm mã cho mỗi thành phần dựa trên tổng số câu lệnh trong toàn bộ ứng dụng (trong trường hợp này, có 82.931 câu lệnh).

Addison nhận thấy rằng hầu hết các thành phần được liệt kê trong Bảng 5-2 có kích thước tương đối giống nhau, ngoại trừ thành phần Báo cáo (ss.reporting) chiếm 33% mã nguồn. Vì thành phần Báo cáo lớn hơn đáng kể so với các thành phần khác (được minh họa trong Hình 5-2), Addison đã quyết định tách thành phần này ra để giảm kích thước tổng thể của nó.

Figure 5-2. The Reporting component is too big and should be broken apart

Sau khi thực hiện phân tích, Addison nhận thấy rằng thành phần báo cáo chứa mã nguồn thực hiện ba loại báo cáo:

• Báo cáo vé (báo cáo nhân khẩu học vé, báo cáo số vé theo ngày/tuần/tháng, báo cáo thời gian giải quyết vé, v.v.)

• Báo cáo chuyên gia (báo cáo sử dụng chuyên gia, báo cáo phân phối chuyên gia, và các báo cáo khác)

• Báo cáo tài chính (báo cáo chi phí sửa chữa, báo cáo chi phí chuyên gia, báo cáo lợi nhuận, v.v.)

Addison cũng đã xác định mã code chung (chung) mà tất cả các danh mục báo cáo sử dụng, chẳng hạn như tiện ích chung, máy tính, truy vấn dữ liệu chung, phân phối báo cáo và định dạng dữ liệu chung. Addison đã tạo ra một câu chuyện kiến trúc (xem “Câu chuyện Kiến trúc”) cho việc tái cấu trúc này và giải thích nó cho nhóm phát triển. Sydney, một trong những lập trình viên của Đội Sysops được giao câu chuyện kiến trúc, đã tái cấu trúc mã code để tách rời thành phần Báo cáo đơn thành bốn thành phần riêng biệt—một thành phần Chung của Báo cáo chứa mã chung và ba thành phần khác (Báo cáo Vé, Báo cáo Chuyên gia và Báo cáo Tài chính), mỗi thành phần đại diện cho một khu vực báo cáo chức năng, như minh họa trong Hình 5-3.

Figure 5-3. The large Reporting component broken into smaller reporting components

Sau khi Sydney thực hiện các thay đổi, Addison đã phân tích lại mã và xác minh rằng tất cả các thành phần bây giờ đã được phân phối khá đồng đều về kích thước. Addison đã ghi lại kết quả của việc áp dụng mẫu phân rã này trong Bảng 5-3.

Lưu ý trong Saga Đội Sysops trước đó rằng phần Báo cáo không còn tồn tại như một thành phần trong Bảng 5-3 hoặc Hình 5-3. Mặc dù không gian tên vẫn tồn tại (ss.reporting), nhưng nó không còn được coi là một thành phần, mà là một miền con. Các thành phần đã được tái cấu trúc được liệt kê trong Bảng 5-3 sẽ được sử dụng khi áp dụng mẫu phân rã tiếp theo, Tập Hợp Các Thành Phần Miền Chung.

Pattern Description

Chức năng miền được phân biệt với chức năng hạ tầng ở chỗ chức năng miền là một phần của logic xử lý kinh doanh của một ứng dụng (như thông báo, định dạng dữ liệu và xác thực dữ liệu) và chỉ chung cho một số quy trình, trong khi chức năng hạ tầng mang tính chất vận hành (như ghi log, thu thập số liệu và bảo mật) và chung cho tất cả các quy trình.

Việc hợp nhất các chức năng miền chung giúp loại bỏ các dịch vụ trùng lặp khi tách rời một hệ thống monolithic. Thường thì chỉ có những khác biệt rất tinh tế giữa các chức năng miền chung được sao chép trong toàn bộ ứng dụng, và những khác biệt này có thể được giải quyết dễ dàng trong một dịch vụ chung duy nhất (hoặc thư viện chia sẻ).

Việc tìm kiếm chức năng miền chung chủ yếu là một quy trình thủ công, nhưng một số tự động hóa có thể được sử dụng để hỗ trợ trong nỗ lực này (xem “Chức năng Fitness cho Quản trị”). Một gợi ý cho thấy việc xử lý miền chung tồn tại trong ứng dụng là việc sử dụng các lớp chia sẻ giữa các thành phần hoặc cấu trúc kế thừa chung được nhiều thành phần sử dụng. Lấy ví dụ, một tệp lớp có tên SMTPConnection trong một mã nguồn lớn được sử dụng bởi năm lớp, tất cả nằm trong các namespace khác nhau (các thành phần). Kịch bản này là một chỉ báo tốt cho thấy chức năng thông báo email chung đã lan rộng khắp ứng dụng và có thể là một ứng cử viên tốt cho việc hợp nhất.

Một cách khác để xác định chức năng miền chung là thông qua tên của một thành phần logic hoặc không gian tên tương ứng của nó. Hãy xem xét các thành phần sau (được biểu thị dưới dạng không gian tên) trong một mã nguồn lớn:

• Kiểm toán vé (penultimate.ss.ticket.audit)

• Kiểm toán hóa đơn

• Kiểm toán khảo sát (penultimate.ss.survey.audit)

Lưu ý rằng mỗi thành phần trong số này (Kiểm toán Vé, Kiểm toán Thanh toán và Kiểm toán Khảo sát) đều có điểm chung là ghi lại hành động đã thực hiện và người dùng yêu cầu hành động vào một bảng kiểm toán. Mặc dù ngữ cảnh có thể khác nhau, nhưng kết quả cuối cùng là giống nhau - chèn một hàng vào bảng kiểm toán. Chức năng miền chung này có thể được hợp nhất vào một thành phần mới có tên penultimate.ss.shared.audit, dẫn đến việc giảm thiểu sự trùng lặp mã và cũng giảm số lượng dịch vụ trong kiến trúc phân tán kết quả.

Không phải tất cả các chức năng miền chung đều trở thành dịch vụ chia sẻ. Thay vào đó, mã chung có thể được tập hợp vào một thư viện chia sẻ, được liên kết với mã trong quá trình biên dịch. Những ưu và nhược điểm của việc sử dụng dịch vụ chia sẻ thay vì thư viện chia sẻ được thảo luận chi tiết trong Chương 8.

Fitness Functions for Governance

Tự động hóa việc quản lý chức năng miền chung là khá khó khăn do tính chủ quan trong việc xác định chức năng chung và phân loại nó thành chức năng miền so với chức năng hạ tầng. Hầu hết, các hàm sinh sản được sử dụng để quản lý mẫu này vì vậy thường là bán tự động. Tuy nhiên, có một số cách để tự động hóa việc quản lý nhằm hỗ trợ trong việc giải thích thủ công các chức năng miền chung. Các hàm sinh sản sau đây có thể hỗ trợ trong việc tìm kiếm chức năng miền chung.

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Locate possible duplicate component node names that are not in the exclusion # list stored in a datastore LIST excluded_leaf_node_list = read_datastore() LIST leaf_node_list LIST common_component_list FOREACH component IN component_list { leaf_name = get_last_node(component) IF leaf_name IN leaf_node_list AND leaf_name NOT IN excluded_leaf_node_list { ADD component TO common_component_list } ELSE { ADD leaf_name TO leaf_node_list } } # Send an alert if any possible common components were found IF common_component_list NOT EMPTY { send_alert(common_component_list) }

# Walk the directory structure, creating namespaces for each complete path and a list # of source file names for each component LIST component_list = identify_components(root_directory) LIST source_file_list = get_source_files(root_directory) MAP component_source_file_map FOREACH component IN component_list { LIST component_source_file_list = get_source_files(component) ADD component, component_source_file_list TO component_source_file_map } # Locate possible common source file usage across components that are not in # the exclusion list stored in a datastore LIST excluded_source_file_list = read_datastore() LIST common_source_file_list FOREACH source_file IN source_file_list { SET count TO 0 FOREACH component,component_source_file_list IN component_source_file_map { IF source_file IN component_source_file_list { ADD 1 TO count } } IF count > 1 AND source_file NOT IN excluded_source_file_list { ADD source_file TO common_source_file_list } } # Send an alert if any source files are used in multiple components IF common_source_file_list NOT EMPTY { send_alert(common_source_file_list) }

Sysops Squad Saga: Gathering Common Components

Thứ Sáu, ngày 5 tháng 11, 10:34

Sau khi xác định và phân loại các thành phần trong ứng dụng Sysops Squad, Addison đã áp dụng mẫu Tập hợp Các thành phần Miền Chung để xem có chức năng chung nào giữa các thành phần không. Từ danh sách các thành phần trong Bảng 5-3, Addison nhận thấy có ba thành phần liên quan đến việc thông báo cho khách hàng của Sysops Squad và đã liệt kê chúng trong Bảng 5-4.

Khi mỗi thành phần thông báo này có một ngữ cảnh khác nhau để thông báo cho khách hàng, Addison nhận ra rằng chúng đều có một điểm chung – chúng đều gửi thông tin cho khách hàng. Hình 5-4 minh họa các thành phần thông báo chung này trong ứng dụng Sysops Squad.

Nhận thấy rằng mã nguồn chứa trong các thành phần này cũng rất giống nhau, Addison đã tham khảo ý kiến của Austen (kiến trúc sư khác trong nhóm Sysops). Austen thích ý tưởng về một thành phần thông báo duy nhất, nhưng lo ngại về việc ảnh hưởng đến mức độ kết nối tổng thể giữa các thành phần. Addison đồng ý rằng đây có thể là một vấn đề và đã điều tra thêm về sự đánh đổi này.

Figure 5-4. Notification functionality is duplicated throughout the application

Addison đã phân tích mức độ kết nối vào (kết nối đến) của các thành phần thông báo trong nhóm Sysops hiện tại và đưa ra các chỉ số kết nối kết quả được liệt kê trong Bảng 5-5, trong đó “CA” đại diện cho số lượng các thành phần khác yêu cầu thành phần đó (kết nối đến).

Addison sau đó nhận thấy rằng nếu chức năng thông báo khách hàng được hợp nhất vào một thành phần duy nhất, mức độ liên kết cho thành phần duy nhất đó tăng lên mức độ liên kết đầu vào là 5, như được trình bày trong Bảng 5-6.

Addison đã mang những phát hiện này đến cho Austen, và họ đã thảo luận về kết quả. Những gì họ phát hiện là, trong khi thành phần hợp nhất mới có mức độ kết nối vào khá cao, nhưng điều đó không ảnh hưởng đến mức độ kết nối vào tổng thể để thông báo cho khách hàng. Nói cách khác, ba thành phần riêng biệt có tổng mức độ kết nối vào là 5, nhưng thành phần hợp nhất duy nhất cũng có mức độ kết nối vào là 5.

Addison và Austen đều nhận ra tầm quan trọng của việc phân tích mức độ kết nối sau khi hợp nhất các chức năng miền chung. Trong một số trường hợp, việc kết hợp các chức năng miền chung thành một thành phần hợp nhất duy nhất đã làm tăng mức độ kết nối của thành phần đó, dẫn đến việc có quá nhiều phụ thuộc vào một thành phần chung trong ứng dụng. Tuy nhiên, trong trường hợp này, cả Addison và Austen đều cảm thấy thoải mái với phân tích kết nối, và đã đồng ý hợp nhất chức năng thông báo để giảm sự trùng lặp cả về mã lệnh lẫn chức năng.

Addison đã viết một câu chuyện kiến trúc để kết hợp tất cả các chức năng thông báo vào một không gian tên duy nhất đại diện cho một thành phần Thông báo chung. Sydney, được giao nhiệm vụ cho câu chuyện kiến trúc, đã tái cấu trúc mã nguồn, tạo ra một thành phần duy nhất cho thông báo khách hàng, như được minh họa trong Hình 5-5.

Figure 5-5. Notification functionality is consolidated into a new single component called Notification

Bảng 5-7 cho thấy các thành phần đã được tạo ra sau khi Sydney triển khai câu chuyện kiến trúc mà Addison đã tạo ra. Lưu ý rằng các thành phần Thông báo Khách hàng (ss.customer.notification), Thông báo Vé (ss.ticket.notify), và Thông báo Khảo sát (ss.survey.notify) đã bị xóa, và mã nguồn đã được chuyển đến thành phần Thông báo hợp nhất mới (ss.notification).

Pattern Description

Khi không gian tên đại diện cho một thành phần cụ thể được mở rộng (nói cách khác, một nút khác được thêm vào không gian tên hoặc cấu trúc thư mục), không gian tên hoặc thư mục trước đó sẽ không còn đại diện cho một thành phần nữa, mà thay vào đó là một miền con. Để minh họa cho điểm này, hãy xem chức năng khảo sát khách hàng trong ứng dụng Sysops Squad được đại diện bởi hai thành phần: Khảo sát (ss.survey) và Mẫu khảo sát (ss.survey.templates). Lưu ý trong Bảng 5-8 cách không gian tên ss.survey, chứa năm tệp lớp được sử dụng để quản lý và thu thập các cuộc khảo sát, được mở rộng với không gian tên ss.survey.templates để bao gồm bảy lớp đại diện cho từng loại khảo sát gửi đến khách hàng.

Trong khi cấu trúc này có vẻ hợp lý từ quan điểm của nhà phát triển để giữ mã mẫu tách biệt với quy trình khảo sát, nó tạo ra một số vấn đề vì Mẫu Khảo sát, như một thành phần, sẽ được coi là một phần của thành phần Khảo sát. Người ta có thể bị cám dỗ để xem Mẫu Khảo sát như một tiểu thành phần của Khảo sát, nhưng sau đó các vấn đề phát sinh khi cố gắng hình thành các dịch vụ từ những thành phần này—cả hai thành phần nên nằm trong một dịch vụ duy nhất gọi là Khảo sát, hay Mẫu Khảo sát nên là một dịch vụ riêng biệt so với dịch vụ Khảo sát?

Chúng tôi đã giải quyết tình huống này bằng cách định nghĩa một thành phần là nút cuối cùng (hoặc nút lá) của cấu trúc không gian tên hoặc thư mục. Với định nghĩa này, ss.survey.templates là một thành phần, trong khi ss.survey sẽ được coi là một miền con, không phải là một thành phần. Chúng tôi cũng định nghĩa các không gian tên như ss.survey là không gian tên gốc vì chúng được mở rộng với các nút không gian tên khác (trong trường hợp này, .templates).

Lưu ý rằng không gian tên gốc ss.survey trong Bảng 5-8 chứa năm tệp lớp. Chúng tôi gọi những tệp lớp này là các lớp mồ côi vì chúng không thuộc về bất kỳ thành phần nào có thể xác định được. Nhớ rằng một thành phần được xác định bởi một nút lá không gian tên chứa mã nguồn. Bởi vì không gian tên ss.survey đã được mở rộng để bao gồm .templates, ss.survey không còn được coi là một thành phần và do đó không nên chứa bất kỳ tệp lớp nào.

Các thuật ngữ và định nghĩa tương ứng sau đây rất quan trọng để hiểu và áp dụng mẫu phân rã Flatten Components:

Component

Một tập hợp các lớp được nhóm lại trong một không gian tên nút lá, thực hiện một số chức năng cụ thể nào đó trong ứng dụng (chẳng hạn như xử lý thanh toán hoặc chức năng khảo sát khách hàng).

Root namespace

Một nút không gian tên đã được mở rộng bởi một nút không gian tên khác. Ví dụ, với các không gian tên ss.survey và ss.survey.templates, ss.survey sẽ được coi là một không gian tên gốc vì nó được mở rộng bởi .templates. Các không gian tên gốc đôi khi cũng được gọi là các tên miền con.

Orphaned classes

Các lớp nằm trong một không gian tên gốc và do đó không có thành phần xác định nào liên quan đến chúng.

Các định nghĩa này được minh họa trong Hình 5-6, nơi hộp có ký hiệu C đại diện cho mã nguồn nằm trong không gian tên đó. Sơ đồ này (và tất cả các sơ đồ tương tự) được vẽ từ dưới lên nhằm nhấn mạnh khái niệm về các ngọn đồi trong ứng dụng, cũng như nhấn mạnh khái niệm về việc các không gian tên xây dựng dựa vào nhau.

Figure 5-6. Components, root namespaces, and orphaned classes (C box denotes source code)

Lưu ý rằng vì cả ss.survey và ss.ticket đều được mở rộng qua các nút không gian tên khác, nên những không gian tên đó được xem là không gian tên gốc, và các lớp chứa trong những không gian tên gốc đó do đó được xem là các lớp mồ côi (thuộc về không thành phần nào được xác định). Vì vậy, các thành phần duy nhất được biểu thị trong Hình 5-6 là ss.survey.templates, ss.login, ss.ticket.assign và ss.ticket.route.

Mô hình phân rã Các thành phần Phẳng được sử dụng để di chuyển các lớp mồ côi nhằm tạo ra các thành phần xác định rõ ràng chỉ tồn tại như là các nút lá trong một thư mục hoặc không gian tên, từ đó tạo ra các miền phụ xác định rõ ràng (không gian tên gốc). Chúng tôi gọi việc làm phẳng các thành phần là việc phân tách (hoặc xây dựng) các không gian tên trong một ứng dụng để loại bỏ các lớp mồ côi. Ví dụ, một cách để làm phẳng không gian tên gốc ss.survey trong Hình 5-6 và loại bỏ các lớp mồ côi là chuyển mã nguồn chứa trong không gian tên ss.survey.templates xuống không gian tên ss.survey, do đó biến ss.survey thành một thành phần duy nhất (.survey giờ đây là nút lá của không gian tên đó). Tùy chọn làm phẳng này được minh họa trong Hình 5-7.

Figure 5-7. Survey is flattened by moving the survey template code into the .survey namespace

Ngoài ra, việc làm phẳng cũng có thể được áp dụng bằng cách lấy mã nguồn trong ss.survey và áp dụng phân tích chức năng hoặc thiết kế hướng miền để xác định các lĩnh vực chức năng riêng biệt trong không gian tên gốc, từ đó hình thành các thành phần từ những lĩnh vực chức năng đó. Ví dụ, giả sử chức năng trong không gian tên ss.survey tạo và gửi một khảo sát cho khách hàng, và sau đó xử lý một khảo sát hoàn thành nhận từ khách hàng. Hai thành phần có thể được tạo ra từ không gian tên ss.survey: ss.survey.create, thành phần tạo và gửi khảo sát, và ss.survey.process, thành phần xử lý một khảo sát nhận từ khách hàng. Hình thức làm phẳng này được minh họa trong Hình 5-8.

Figure 5-8. Survey is flattened by moving the orphaned classes to new leaf nodes ( components)

Tip

Bất kể hướng làm phẳng nào, hãy đảm bảo rằng các tệp mã nguồn chỉ nằm trong các không gian tên hoặc thư mục lá, để mã nguồn có thể luôn được xác định trong một thành phần cụ thể.

Một kịch bản phổ biến khác mà mã nguồn mồ côi có thể tồn tại trong không gian tên gốc là khi mã được chia sẻ bởi các thành phần khác trong không gian tên đó. Hãy xem xét ví dụ trong Hình 5-9, nơi chức năng khảo sát khách hàng nằm trong ba thành phần (ss.survey.templates, ss.survey.create và ss.survey.process), nhưng mã chung (chẳng hạn như giao diện, lớp trừu tượng, tiện ích chung) nằm trong không gian tên gốc ss.survey.

Figure 5-9. Shared code in .survey is considered orphaned classes and should be moved

Các lớp chia sẻ trong ss.survey vẫn được coi là lớp mồ côi, mặc dù chúng đại diện cho mã chia sẻ. Áp dụng mẫu Phẳng các Thành phần sẽ di chuyển những lớp mồ côi chia sẻ đó vào một thành phần mới gọi là ss.survey.shared, do đó loại bỏ tất cả các lớp mồ côi khỏi phân miền ss.survey, như được mô tả trong Hình 5-10.

Figure 5-10. Shared survey code is moved into its own component

Lời khuyên của chúng tôi khi di chuyển mã chia sẻ sang một thành phần riêng biệt (tên không gian nút lá) là chọn một từ không được sử dụng trong bất kỳ mã nguồn nào hiện có trong miền, chẳng hạn như .sharedcode, .commoncode, hoặc một tên duy nhất nào đó. Điều này cho phép kiến trúc sư tạo ra các chỉ số dựa trên số lượng thành phần được chia sẻ trong mã nguồn, cũng như tỷ lệ phần trăm mã nguồn được chia sẻ trong ứng dụng. Đây là một chỉ báo tốt về khả năng tách biệt ứng dụng đơn thể. Ví dụ, nếu tổng số lệnh trong tất cả các không gian tên kết thúc bằng .sharedcode chiếm 45% tổng mã nguồn, khả năng cao là việc chuyển sang kiến trúc phân tán sẽ dẫn đến quá nhiều thư viện chung và trở nên khó khăn để duy trì vì các phụ thuộc vào thư viện chung.

Một chỉ số tốt khác liên quan đến việc phân tích mã chia sẻ là số lượng thành phần kết thúc bằng .sharedcode (hoặc bất kỳ nút không gian tên chia sẻ chung nào được sử dụng). Chỉ số này cung cấp cho kiến trúc sư cái nhìn về số lượng thư viện chia sẻ (JAR, DLL, và những thứ tương tự) hoặc dịch vụ chia sẻ sẽ hình thành từ việc phân tách ứng dụng đơn khối.

Fitness Functions for Governance

Việc áp dụng mô hình phân rã Flatten Components liên quan đến một lượng chủ quan khá lớn. Ví dụ, mã từ các nút lá có nên được hợp nhất vào không gian tên gốc hay mã trong không gian tên gốc có nên được chuyển vào các nút lá? Tuy nhiên, hàm fitness sau đây có thể hỗ trợ trong việc tự động hóa quản lý việc giữ cho các thành phần phẳng (chỉ ở các nút lá).

# Walk the directory structure, creating namespaces for each complete path LIST component_list = identify_components(root_directory) # Send an alert if a non-leaf node in any component contains source files FOREACH component IN component_list { LIST component_node_list = get_nodes(component) FOREACH node IN component_node_list { IF contains_code(node) AND NOT last_node(component_node_list) { send_alert(component) } } }

Sysops Squad Saga: Flattening Components

Thứ tư, ngày 10 tháng 11, 11:10

Sau khi áp dụng “Mô hình Tập hợp các Thành phần Miền Chung”, Addison đã phân tích kết quả trong Bảng 5-7 và nhận thấy rằng các thành phần Khảo sát và Vé chứa các lớp mồ côi. Addison đã làm nổi bật những thành phần này trong Bảng 5-9 và Hình 5-11.

Figure 5-11. The Survey and Ticket components contain orphaned classes and should be flattened

Addison quyết định giải quyết các thành phần ticketing trước. Biết rằng việc làm phẳng các thành phần có nghĩa là loại bỏ mã nguồn ở các nút không lá, Addison có hai lựa chọn: hợp nhất mã contained trong các thành phần phân bổ vé và định tuyến vé vào thành phần ss.ticket, hoặc chia nhỏ 45 lớp trong thành phần ss.ticket thành các thành phần riêng biệt, từ đó biến ss.ticket thành một miền con. Addison đã thảo luận về những lựa chọn này với Sydney (một trong những lập trình viên của đội Sysops), và dựa trên sự phức tạp và sự thay đổi thường xuyên trong chức năng phân bổ vé, đã quyết định giữ các thành phần đó tách biệt và di chuyển mã bị bỏ rơi từ không gian tên gốc ss.ticket vào các không gian tên khác, từ đó hình thành nên các thành phần mới.

Với sự giúp đỡ từ Sydney, Addison đã phát hiện rằng 45 lớp trẻ mồ côi nằm trong không gian tên ss.ticket đã triển khai các chức năng quản lý vé sau đây:

• Tạo và bảo trì vé (tạo vé, cập nhật vé, hủy vé, v.v.)

• Logic hoàn thành vé

• Mã chia sẻ chung cho hầu hết các chức năng đặt vé.

Vì chức năng phân công vé và định tuyến vé đã có trong các thành phần riêng (ss.ticket.assign và ss.ticket.route, tương ứng), Addison đã tạo một câu chuyện kiến trúc để chuyển mã nguồn chứa trong không gian tên ss.ticket sang ba thành phần mới, như được trình bày trong Bảng 5-10.

Addison sau đó đã xem xét chức năng khảo sát. Làm việc với Sydney, Addison nhận thấy rằng chức năng khảo sát hiếm khi thay đổi và không quá phức tạp. Sydney đã nói chuyện với Skyler, nhà phát triển của đội Sysops đã tạo ra không gian tên ss.survey.templates, và phát hiện ra rằng không có lý do thuyết phục để tách các mẫu khảo sát thành không gian tên riêng (“Nó chỉ có vẻ là một ý tưởng hay vào thời điểm đó,” Skyler nói). Với thông tin này, Addison đã tạo ra một câu chuyện kiến trúc để di chuyển bảy tệp lớp từ ss.survey.templates vào không gian tên ss.survey và loại bỏ thành phần ss.survey.template, như được trình bày trong Bảng 5-11.

Sau khi áp dụng mẫu Flatten Components (được minh họa trong Hình 5-12), Addison nhận thấy rằng không có “đồi” (các thành phần chồng lên nhau) hoặc các lớp mồ côi và tất cả các thành phần chỉ được chứa trong các nút lá của không gian tên tương ứng.

Figure 5-12. The Survey component was flattened into a single component, whereas the Ticket component was raised up and flattened, creating a Ticket subdomain

Addison đã ghi lại kết quả của những nỗ lực tái cấu trúc cho đến nay trong việc áp dụng các mẫu phân tách này và liệt kê chúng trong Bảng 5-12.

Pattern Description

Mục đích của mẫu Xác định Các phụ thuộc Thành phần là phân tích các phụ thuộc đến và đi (sự kết nối) giữa các thành phần để xác định hình dạng của đồ thị phụ thuộc dịch vụ có thể trông như thế nào sau khi tách rời ứng dụng nguyên khối. Mặc dù có nhiều yếu tố trong việc xác định mức độ chi tiết đúng cho một dịch vụ (xem Chương 7), mỗi thành phần trong ứng dụng nguyên khối đều có thể là một ứng cử viên dịch vụ (tuỳ thuộc vào kiểu kiến trúc phân tán mục tiêu). Vì lý do này, việc hiểu rõ các tương tác và phụ thuộc giữa các thành phần là rất quan trọng.

Cần lưu ý rằng mẫu này đề cập đến sự phụ thuộc của các thành phần, chứ không phải sự phụ thuộc của các lớp riêng lẻ trong một thành phần. Một sự phụ thuộc thành phần được hình thành khi một lớp từ một thành phần (tên không gian) tương tác với một lớp từ một thành phần khác (tên không gian). Ví dụ, giả sử lớp CustomerSurvey trong thành phần ss.survey gọi một phương thức trong lớp CustomerNotification trong thành phần ss.notification để gửi khảo sát khách hàng, như được minh họa trong mã giả ở Ví dụ 5-7.

namespace ss.survey class CustomerSurvey { function createSurvey { ... } function sendSurvey { ... ss.notification.CustomerNotification.send(customer_id, survey) } }

Lưu ý sự phụ thuộc giữa các thành phần Khảo sát và Thông báo, vì lớp CustomerNotification được sử dụng bởi lớp CustomerSurvey nằm ngoài không gian tên ss.survey. Cụ thể, thành phần Khảo sát sẽ có một sự phụ thuộc efferent (hoặc outgoing) vào thành phần Thông báo, và thành phần Thông báo sẽ có một sự phụ thuộc afferent (hoặc incoming) vào thành phần Khảo sát.

Lưu ý rằng các lớp trong một thành phần cụ thể có thể là một mớ hỗn độn liên kết chặt chẽ của nhiều phụ thuộc, nhưng điều đó không quan trọng khi áp dụng mẫu này—điều quan trọng chỉ là những phụ thuộc giữa các thành phần.

Nhiều công cụ có sẵn có thể hỗ trợ trong việc áp dụng mẫu này và hình dung các phụ thuộc của thành phần. Ngoài ra, nhiều IDE hiện đại có các plug-in sẽ tạo ra các sơ đồ phụ thuộc của các thành phần hoặc không gian tên trong một mã nguồn cụ thể. Những hình ảnh trực quan này có thể hữu ích trong việc trả lời ba câu hỏi chính được đặt ra ở đầu phần này.

Ví dụ, hãy xem xét sơ đồ phụ thuộc được hiển thị trong Hình 5-13, nơi các hộp đại diện cho các thành phần (không phải lớp), và các đường thẳng đại diện cho các điểm kết nối giữa các thành phần. Lưu ý rằng chỉ có một phụ thuộc duy nhất giữa các thành phần trong sơ đồ này, làm cho ứng dụng này trở thành một ứng viên tốt để phân tách vì các thành phần này độc lập về mặt chức năng với nhau.

Figure 5-13. A monolithic application with minimal component dependencies takes less effort to break apart (golf ball sizing)

Với một sơ đồ phụ thuộc như Hình 5-13, câu trả lời cho ba câu hỏi chính là như sau:

1. Có khả thi để tách rời ứng dụng monolithic hiện có không? Có.

2. Mức độ nỗ lực tổng thể cho việc di chuyển này là khoảng nào? Một quả bóng golf (tương đối đơn giản).

3. Điều này sẽ là viết lại mã hay là tái cấu trúc mã? Tái cấu trúc (di chuyển mã hiện có vào các dịch vụ được triển khai riêng biệt)

Bây giờ hãy nhìn vào sơ đồ phụ thuộc được hiển thị trong Hình 5-14. Thật không may, sơ đồ này là điển hình cho các phụ thuộc giữa các thành phần trong hầu hết các ứng dụng doanh nghiệp. Lưu ý đặc biệt rằng bên trái của sơ đồ này có mức độ gắn bó cao nhất, trong khi bên phải trông khả thi hơn nhiều để tách rời.

Figure 5-14. A monolithic application with a high number of component dependencies takes more effort to break apart (basketball sizing)

Với mức độ gắn bó chặt chẽ giữa các thành phần này, câu trả lời cho ba câu hỏi quan trọng không được lạc quan lắm:

1. Có khả thi để tách rời ứng dụng đơn khối hiện tại không? Có thể...

2. Mức độ nỗ lực tổng thể cho việc di chuyển này là gì? Một quả bóng rổ (khó hơn nhiều).

3. Đây sẽ là việc viết lại mã hay cải tiến mã? Có khả năng là một sự kết hợp giữa một số cải tiến và một số viết lại mã hiện có.

Cuối cùng, hãy xem xét sơ đồ phụ thuộc được minh họa trong Hình 5-15. Trong trường hợp này, kiến trúc sư nên quay lại và chạy theo hướng ngược lại nhanh nhất có thể!

Figure 5-15. A monolithic application with too many component dependencies is not feasible to break apart (airliner sizing)

Câu trả lời cho ba câu hỏi chính đối với các ứng dụng có ma trận phụ thuộc thành phần kiểu này không có gì bất ngờ:

1. Không, việc tách rời ứng dụng đơn khối hiện tại là không khả thi.

2. Mức độ nỗ lực tổng thể cho việc chuyển giao này là gì? Một hãng hàng không.

3. Điều này sẽ là viết lại mã hay tái cấu trúc mã? Viết lại hoàn toàn ứng dụng.

Chúng tôi không thể nhấn mạnh đủ tầm quan trọng của những loại sơ đồ hình ảnh này khi tách rời một ứng dụng nguyên khối. Về bản chất, những sơ đồ này hình thành một radar để xác định vị trí của kẻ thù (sự kết nối chặt chẽ giữa các thành phần), và cũng tạo ra một bức tranh về cách mà ma trận phụ thuộc dịch vụ sẽ như thế nào nếu ứng dụng nguyên khối được tách ra thành một kiến trúc phân tán cao.

Theo kinh nghiệm của chúng tôi, sự liên kết giữa các thành phần là một trong những yếu tố quan trọng nhất trong việc xác định thành công (và tính khả thi) của nỗ lực di cư từ monolithic. Việc xác định và hiểu mức độ liên kết giữa các thành phần không chỉ cho phép kiến trúc sư xác định tính khả thi của nỗ lực di cư, mà còn cho họ biết nên mong đợi điều gì về mức độ công sức tổng thể. Đáng tiếc, rất thường xuyên chúng tôi thấy các đội ngũ lao vào việc phân tách một ứng dụng monolithic thành các microservices mà không có bất kỳ phân tích hay hình ảnh nào về hình thức của ứng dụng monolithic. Và không có gì ngạc nhiên, những đội ngũ đó gặp khó khăn trong việc phá vỡ các ứng dụng monolithic của họ.

Mô hình này không chỉ hữu ích cho việc xác định mức độ liên kết tổng thể của các thành phần trong một ứng dụng, mà còn để xác định cơ hội tái cấu trúc các phụ thuộc trước khi tách rời ứng dụng. Khi phân tích mức độ liên kết giữa các thành phần, điều quan trọng là phải phân tích cả liên kết đến (afferent) (thường được ký hiệu là CA trong hầu hết các công cụ), và liên kết đi (efferent) (thường được ký hiệu là CE trong hầu hết các công cụ). CT, hoặc liên kết tổng, là tổng của cả liên kết đến và liên kết đi.

Nhiều lần, việc tách rời một thành phần có thể giảm mức độ kết nối của thành phần đó. Ví dụ, giả sử thành phần A có mức độ kết nối hướng vào là 20 (nghĩa là, 20 thành phần khác phụ thuộc vào chức năng của thành phần này). Điều này không nhất thiết có nghĩa là tất cả 20 thành phần khác đều cần tất cả chức năng từ thành phần A. Có thể 14 trong số các thành phần khác chỉ cần một phần nhỏ chức năng có trong thành phần A. Việc tách thành phần A thành hai thành phần khác nhau (thành phần A1 chứa chức năng nhỏ hơn, kết nối với nhau, và thành phần A2 chứa phần lớn chức năng) làm giảm mức độ kết nối hướng vào của thành phần A2 xuống còn 6, trong khi thành phần A1 có mức độ kết nối hướng vào là 14.

Fitness Functions for Governance

Hai cách để tự động hóa việc quản lý các thành phần phụ thuộc là đảm bảo không có thành phần nào có "quá nhiều" phụ thuộc, và hạn chế một số thành phần không được kết hợp với các thành phần khác. Các hàm đánh giá được mô tả dưới đây là một số cách để quản lý các loại phụ thuộc này.

# Walk the directory structure, gathering components and the source code files # contained within those components LIST component_list = identify_components(root_directory) MAP component_source_file_map FOREACH component IN component_list { LIST component_source_file_list = get_source_files(component) ADD component, component_source_file_list TO component_source_file_map } # Determine how many references exist for each source file and send an alert if # the total dependency count is greater than 15 FOREACH component,component_source_file_list IN component_source_file_map { FOREACH source_file IN component_source_file_list { incoming count = used_by_other_components(source_file, component_source_file_map) { outgoing_count = uses_other_components(source_file) { total_count = incoming count + outgoing count } IF total_count > 15 { send_alert(component, total_count) } }

public void ticket_maintenance_cannot_access_expert_profile() { noClasses().that() .resideInAPackage("..ss.ticket.maintenance..") .should().accessClassesThat() .resideInAPackage("..ss.expert.profile..") .check(myClasses); }

Sysops Squad Saga: Identifying Component Dependencies

Thứ Hai, ngày 15 tháng 11, 09:45

Sau khi đọc về mô hình Xác định Phụ thuộc Thành phần, Addison tự hỏi ma trận phụ thuộc ứng dụng của đội Sysops Squad trông như thế nào và liệu có khả thi để tách ứng dụng ra hay không. Addison đã sử dụng một tiện ích mở rộng IDE để tạo ra một sơ đồ phụ thuộc thành phần của ứng dụng Sysops Squad hiện tại. Ban đầu, Addison cảm thấy hơi nản lòng vì Hình 5-16 cho thấy nhiều phụ thuộc giữa các thành phần của ứng dụng Sysops Squad.

Figure 5-16. Component dependencies in the Sysops Squad application

Tuy nhiên, sau khi phân tích thêm, Addison nhận thấy rằng thành phần Thông báo có nhiều phụ thuộc nhất, điều này không có gì ngạc nhiên vì đây là thành phần dùng chung. Tuy nhiên, Addison cũng nhận thấy có nhiều phụ thuộc trong các thành phần Xử lý vé và Báo cáo. Cả hai lĩnh vực miền này đều có một thành phần cụ thể cho mã dùng chung (giao diện, lớp trợ giúp, lớp thực thể, và v.v.). Nhận ra rằng cả mã dùng chung của hệ thống xử lý vé và báo cáo chủ yếu chứa các tham chiếu lớp dựa trên biên dịch và có khả năng sẽ được triển khai dưới dạng thư viện chia sẻ hơn là dịch vụ, Addison đã lọc bỏ các thành phần này để có cái nhìn tốt hơn về các phụ thuộc giữa chức năng cốt lõi của ứng dụng, điều này được minh hoạ trong Hình 5-17.

Figure 5-17. Component dependencies in the Sysops Squad application without shared library dependencies

Sau khi các thành phần chung được lọc ra, Addison nhận thấy rằng các phụ thuộc khá tối thiểu. Addison đã trình bày kết quả này cho Austen, và cả hai đều đồng ý rằng hầu hết các thành phần đều tương đối độc lập và có vẻ như ứng dụng Sysops Squad là một ứng cử viên tốt để tách ra thành một kiến trúc phân tán.

Pattern Description

Xác định các miền thành phần—nhóm các thành phần thực hiện một số chức năng liên quan—là một phần quan trọng trong việc tách rời bất kỳ ứng dụng đơn khối nào. Nhớ lại lời khuyên từ Chương 4:

Khi tách rời các ứng dụng đơn khối, hãy xem xét việc chuyển sang kiến trúc dựa trên dịch vụ như một bước đệm để đến các kiến trúc phân tán khác.

Tạo ra các miền thành phần là một cách hiệu quả để xác định những gì sẽ trở thành dịch vụ miền trong kiến trúc dựa trên dịch vụ.

Các miền thành phần được thể hiện vật lý trong một ứng dụng thông qua các không gian tên (hoặc thư mục) thành phần. Bởi vì các nút không gian tên có tính chất phân cấp, chúng trở thành một cách tuyệt vời để đại diện cho các miền và tiểu miền chức năng. Kỹ thuật này được minh họa trong Hình 5-18, nơi nút thứ hai trong không gian tên (.customer) đề cập đến miền, nút thứ ba đại diện cho một tiểu miền dưới miền khách hàng (.billing), và nút lá (.payment) đề cập đến thành phần. .MonthlyBilling ở cuối không gian tên này đề cập đến một tệp lớp nằm trong thành phần Payment.

Figure 5-18. Component domains are identified through the namespace nodes

Vì nhiều ứng dụng monolithic cũ được triển khai trước khi thiết kế theo miền trở nên phổ biến, trong nhiều trường hợp việc tái cấu trúc các không gian tên là cần thiết để xác định cấu trúc các miền trong ứng dụng. Ví dụ, hãy xem xét các thành phần được liệt kê trong Bảng 5-13 tạo thành miền Khách hàng trong ứng dụng Sysops Squad.

Chú ý rằng mỗi thành phần đều liên quan đến chức năng của khách hàng, nhưng các không gian tên tương ứng không phản ánh sự liên kết đó. Để nhận diện đúng miền Khách hàng (được thể hiện qua không gian tên ss.customer), các không gian tên cho các thành phần Thanh toán Hoá đơn, Lịch sử Hoá đơn và Hợp đồng Hỗ trợ sẽ phải được sửa đổi để thêm nút .customer ở đầu không gian tên, như đã trình bày trong Bảng 5-14.

Lưu ý trong bảng trước rằng tất cả các chức năng liên quan đến khách hàng (thanh toán, duy trì hồ sơ và duy trì hợp đồng hỗ trợ) hiện được nhóm lại dưới .customer, để mỗi thành phần được sắp xếp theo miền cụ thể đó.

Fitness Functions for Governance

Sau khi đã được tái cấu trúc, việc quản lý các miền thành phần là rất quan trọng để đảm bảo rằng các quy tắc không gian tên được thực thi và không có mã nào tồn tại ngoài bối cảnh của một miền thành phần hoặc miền con. Hàm kiểm tra tự động sau đây có thể được sử dụng để giúp quản lý các miền thành phần khi chúng đã được thiết lập trong ứng dụng đơn thể.

public void restrict_domains() { classes() .should().resideInAPackage("..ss.ticket..") .orShould().resideInAPackage("..ss.customer..") .orShould().resideInAPackage("..ss.admin..") .check(myClasses); }

Sysops Squad Saga: Creating Component Domains

Thứ Năm, 18 tháng 11, 13:15

Addison và Austen đã tham khảo ý kiến của Parker, chủ sở hữu sản phẩm của đội Sysops Squad, và cùng nhau xác định năm lĩnh vực chính trong ứng dụng: lĩnh vực Ticketing (ss.ticket) chứa tất cả các chức năng liên quan đến vé, bao gồm xử lý vé, khảo sát khách hàng và chức năng cơ sở tri thức (KB); lĩnh vực Reporting (ss.reporting) chứa tất cả các chức năng báo cáo; lĩnh vực Customer (ss.customer) chứa hồ sơ khách hàng, thanh toán và hợp đồng hỗ trợ; lĩnh vực Admin (ss.admin) chứa việc bảo trì người dùng và các chuyên gia của đội Sysops Squad; và cuối cùng, lĩnh vực Shared (ss.shared) chứa các chức năng đăng nhập và thông báo được các lĩnh vực khác sử dụng.

Addison đã tạo ra một sơ đồ miền (xem Hình 5-19) cho thấy các miền khác nhau và các nhóm thành phần tương ứng trong mỗi miền, và hài lòng với việc phân nhóm này vì không có thành phần nào bị bỏ sót, và có sự gắn kết tốt giữa các thành phần trong mỗi miền.

Bài tập mà Addison thực hiện trong việc lập sơ đồ và phân nhóm các thành phần là rất quan trọng vì nó đã xác thực các ứng viên miền đã xác định và cũng cho thấy sự cần thiết phải hợp tác với các bên liên quan trong kinh doanh (chẳng hạn như người sở hữu sản phẩm hoặc người tài trợ ứng dụng kinh doanh). Nếu các thành phần không được sắp xếp đúng cách hoặc Addison còn lại với những thành phần không thuộc về đâu, sẽ cần phải hợp tác thêm với Parker (người sở hữu sản phẩm).

Hài lòng rằng tất cả các thành phần đều phù hợp với các miền này, Addison sau đó đã nhìn vào các không gian tên thành phần khác nhau trong Bảng 5-12 sau khi áp dụng “Mô hình Làm phẳng Các Thành phần” và xác định việc cải tiến miền thành phần cần phải diễn ra.

Figure 5-19. The five domains identified (with darkened borders) within the Sysops Squad application

Addison bắt đầu với miền Ticket và thấy rằng trong khi chức năng vé cốt lõi bắt đầu với không gian tên ss.ticket, các thành phần khảo sát và cơ sở kiến thức thì không. Do đó, Addison đã viết một câu chuyện kiến trúc để tái cấu trúc các thành phần được liệt kê trong Bảng 5-15 để phù hợp với miền vé.

Tiếp theo, Addison đã xem xét các thành phần liên quan đến khách hàng và phát hiện rằng các thành phần thanh toán và khảo sát cần được tái cấu trúc để đưa chúng vào miền Khách hàng, đồng thời tạo ra một tiểu miền Thanh toán. Addison đã viết một câu chuyện kiến trúc cho việc tái cấu trúc chức năng miền Khách hàng, như được trình bày trong Bảng 5-16.

Bằng cách áp dụng “Mô hình Xác định và Định cỡ các Thành phần”, Addison đã phát hiện rằng miền báo cáo đã được căn chỉnh và không cần hành động nào thêm với các thành phần báo cáo được liệt kê trong Bảng 5-17.

Addison nhận thấy rằng cả miền Quản trị (Admin) và Chung (Shared) cũng cần được đồng bộ hóa, và quyết định tạo ra một câu chuyện kiến trúc duy nhất cho nỗ lực tái cấu trúc này và liệt kê các thành phần này trong Bảng 5-18. Addison cũng quyết định đổi tên không gian tên ss.expert.profile thành ss.experts để tránh tạo ra một miền con Expert không cần thiết dưới miền Quản trị.

Với mẫu này đã hoàn thành, Addison nhận ra họ đã sẵn sàng để tách rời ứng dụng đơn thể và chuyển sang giai đoạn đầu tiên của kiến trúc phân tán bằng cách áp dụng mẫu Tạo Dịch vụ Miền (được mô tả ở phần tiếp theo).

Pattern Description

Mẫu “Tạo miền thành phần” trước đó tạo ra các miền thành phần được định nghĩa rõ ràng trong một ứng dụng nguyên khối và thể hiện những miền đó thông qua các không gian tên thành phần (hoặc cấu trúc thư mục). Mẫu này lấy những miền thành phần được định nghĩa rõ ràng đó và tách các nhóm thành phần thành các dịch vụ triển khai riêng biệt, được gọi là dịch vụ miền, từ đó tạo ra một kiến trúc dựa trên dịch vụ.

Dưới dạng đơn giản nhất, kiến trúc dựa trên dịch vụ bao gồm một giao diện người dùng mà truy cập từ xa vào các dịch vụ miền thô, tất cả đều chia sẻ một cơ sở dữ liệu đơn khối. Mặc dù có nhiều kiểu hình trong kiến trúc dựa trên dịch vụ (chẳng hạn như tách rời giao diện người dùng, tách cơ sở dữ liệu, thêm cổng API, v.v.), kiểu hình cơ bản được thể hiện trong Hình 5-20 là một điểm khởi đầu tốt cho việc chuyển đổi một ứng dụng đơn khối.

Figure 5-20. The basic topology for a service-based architecture

Ngoài những lợi ích được đề cập trong "Phân tách dựa trên thành phần", việc chuyển sang kiến trúc dựa trên dịch vụ trước tiên cho phép kiến trúc sư và đội ngũ phát triển tìm hiểu thêm về từng dịch vụ miền để xác định xem nó có nên được phân nhỏ thành các dịch vụ nhỏ hơn trong kiến trúc microservices hay để lại dưới dạng dịch vụ miền lớn hơn. Quá nhiều đội ngũ mắc sai lầm khi bắt đầu quá chi tiết, và kết quả là phải chấp nhận tất cả những yếu tố phức tạp của microservices (chẳng hạn như phân tách dữ liệu, quy trình làm việc phân tán, giao dịch phân tán, tự động hóa hoạt động, đóng gói container, v.v.) mà không cần tất cả các dịch vụ microservices chi tiết đó.

Hình 5-21 mô tả cách hoạt động của mô hình Tạo Dịch vụ Miền. Lưu ý trong sơ đồ cách mà miền thành phần Báo cáo được định nghĩa trong "Mô hình Tạo Miền Thành Phần" được tách ra khỏi ứng dụng đơn khối, tạo thành dịch vụ Báo cáo được triển khai riêng biệt.

Figure 5-21. Component domains are moved to external domain services

Một lời khuyên, tuy nhiên: đừng áp dụng mẫu này cho đến khi tất cả các miền thành phần đã được xác định và tái cấu trúc. Điều này giúp giảm số lượng sửa đổi cần thiết cho mỗi dịch vụ miền khi di chuyển các thành phần (và do đó là mã nguồn) xung quanh. Ví dụ, giả sử tất cả các chức năng về đăng ký vé và cơ sở kiến thức trong ứng dụng của Nhóm Sysops được nhóm và tái cấu trúc thành một miền Ticket, và một dịch vụ Ticket mới được tạo ra từ miền đó. Bây giờ giả sử rằng thành phần khảo sát khách hàng (được xác định thông qua không gian tên ss.customer.survey) được coi là một phần của miền Ticket. Vì miền Ticket đã được di chuyển, nên dịch vụ Ticket bây giờ sẽ phải được sửa đổi để bao gồm thành phần Khảo sát. Tốt hơn là hãy sắp xếp và tái cấu trúc tất cả các thành phần vào các miền thành phần trước, sau đó mới bắt đầu di chuyển các miền thành phần đó đến các dịch vụ miền.

Fitness Functions for Governance

Điều quan trọng là giữ cho các thành phần trong mỗi dịch vụ miền phù hợp với miền, đặc biệt nếu dịch vụ miền sẽ được chia nhỏ thành các microservices. Loại hình quản trị này giúp giữ cho các dịch vụ miền không trở thành những dịch vụ đơn thể không có cấu trúc riêng. Hàm kiểm tra phù hợp sau đây đảm bảo rằng không gian tên (và do đó các thành phần) được giữ nhất quán trong một dịch vụ miền.

public void restrict_domain_within_ticket_service() { classes().should().resideInAPackage("..ss.ticket..") .check(myClasses); }

Sysops Squad Saga: Creating Domain Services

Thứ Ba, ngày 23 tháng 11, 09:04

Addison và Austen đã làm việc chặt chẽ với đội ngũ phát triển của Sysops Squad để xây dựng một kế hoạch di chuyển nhằm giai đoạn chuyển đổi từ các miền thành phần sang dịch vụ miền. Họ nhận ra rằng nỗ lực này không chỉ yêu cầu mã trong mỗi miền thành phần được trích xuất khỏi cấu trúc đơn và chuyển đến một không gian làm việc dự án mới, mà còn cần giao diện người dùng giờ đây có thể truy cập từ xa các chức năng trong miền đó.

Dựa trên các miền thành phần được xác định trước đó trong Hình 5-19, nhóm đã di chuyển từng thành phần một, cuối cùng đạt được kiến trúc dựa trên dịch vụ, như được hiển thị trong Hình 5-22. Lưu ý cách mỗi miền đã được xác định trong mẫu trước giờ trở thành một dịch vụ triển khai riêng biệt.

Figure 5-22. Separately deployed domain services result in a distributed Sysops Squad application

Data Disintegrators

Các yếu tố thúc đẩy sự phân tách dữ liệu cung cấp câu trả lời và lý do cho câu hỏi “Khi nào tôi nên xem xét tách rời dữ liệu của mình?” Sáu yếu tố chính thúc đẩy sự phân tách dữ liệu bao gồm:

Change control

Bao nhiêu dịch vụ bị ảnh hưởng bởi sự thay đổi của bảng cơ sở dữ liệu?

Connection management

Cơ sở dữ liệu của tôi có thể xử lý các kết nối cần thiết từ nhiều dịch vụ phân tán không?

Scalability

Cơ sở dữ liệu có thể mở rộng để đáp ứng nhu cầu của các dịch vụ truy cập vào nó không?

Fault tolerance

Có bao nhiêu dịch vụ bị ảnh hưởng bởi sự cố cơ sở dữ liệu hoặc thời gian bảo trì?

Architectural quanta

Một cơ sở dữ liệu chung đơn lẻ có khiến tôi bị ép vào một kiến trúc lượng tử đơn không mong muốn không?

Database type optimization

Tôi có thể tối ưu hóa dữ liệu của mình bằng cách sử dụng nhiều loại cơ sở dữ liệu không?

Mỗi trong những yếu tố gây ra sự phân hủy này sẽ được thảo luận chi tiết trong các phần sau.

Change control

Một trong những nguyên nhân chính dẫn đến sự phân tán dữ liệu là việc kiểm soát các thay đổi trong cấu trúc bảng cơ sở dữ liệu. Việc xóa bảng hoặc cột, thay đổi tên bảng hoặc cột, và thậm chí thay đổi kiểu cột trong bảng sẽ làm hỏng các câu lệnh SQL tương ứng truy cập các bảng đó, và do đó làm hỏng các dịch vụ tương ứng sử dụng các bảng đó. Chúng tôi gọi những loại thay đổi này là thay đổi phá vỡ, trái ngược với việc thêm bảng hoặc cột trong cơ sở dữ liệu, điều này thường không ảnh hưởng đến các truy vấn hoặc ghi hiện có. Không ngạc nhiên khi việc kiểm soát thay đổi bị ảnh hưởng nhiều nhất khi sử dụng cơ sở dữ liệu quan hệ, nhưng các loại cơ sở dữ liệu khác cũng có thể tạo ra vấn đề về kiểm soát thay đổi (xem “Chọn loại cơ sở dữ liệu”).

Như được minh họa trong Hình 6-2, khi có những thay đổi đột phá xảy ra với cơ sở dữ liệu, nhiều dịch vụ phải được cập nhật, kiểm tra và triển khai cùng với những thay đổi của cơ sở dữ liệu. Việc phối hợp này có thể nhanh chóng trở nên khó khăn và dễ xảy ra lỗi khi số lượng các dịch vụ triển khai riêng lẻ chia sẻ cùng một cơ sở dữ liệu gia tăng. Hãy tưởng tượng việc cố gắng phối hợp 42 dịch vụ được triển khai riêng lẻ cho một thay đổi đột phá trong cơ sở dữ liệu!

Figure 6-2. Services impacted by the database change must be deployed together with the database

Việc phối hợp các thay đổi đối với nhiều dịch vụ phân tán cho một thay đổi cơ sở dữ liệu chung chỉ là một phần của câu chuyện. Mối nguy thực sự khi thay đổi một cơ sở dữ liệu chung trong bất kỳ kiến trúc phân tán nào là quên không tính đến các dịch vụ truy cập vào bảng vừa được thay đổi. Như đã minh họa trong Hình 6-3, những dịch vụ đó trở nên không hoạt động trong môi trường sản xuất cho đến khi chúng được thay đổi, kiểm tra và triển khai lại.

Figure 6-3. Services impacted by a database change but forgotten will continue to fail until redeployed

Trong hầu hết các ứng dụng, mối nguy cơ từ các dịch vụ bị quên được giảm thiểu nhờ vào phân tích tác động cẩn thận và kiểm thử hồi quy mạnh mẽ. Tuy nhiên, hãy xem xét một hệ sinh thái microservices với 400 dịch vụ, tất cả đều chia sẻ cùng một cơ sở dữ liệu quan hệ phân cụm cực kỳ sẵn sàng. Hãy tưởng tượng phải chạy quanh tất cả các nhóm phát triển trong nhiều lĩnh vực khác nhau, cố gắng tìm ra dịch vụ nào đang sử dụng bảng đang được thay đổi. Cũng hãy tưởng tượng rằng bạn phải phối hợp, kiểm thử và triển khai tất cả những dịch vụ này cùng nhau như một đơn vị duy nhất, cùng với cơ sở dữ liệu. Suy nghĩ về kịch bản này bắt đầu trở thành một bài tập khiến đầu óc choáng váng, thường dẫn đến một mức độ điên rồ nào đó.

Việc chia nhỏ một cơ sở dữ liệu thành các ngữ cảnh rạch ròi giúp kiểm soát những thay đổi lớn trong cơ sở dữ liệu một cách hiệu quả. Khái niệm ngữ cảnh ranh giới này bắt nguồn từ cuốn sách nổi bật "Thiết kế dựa trên miền" của Eric Evans (Addison-Wesley) và mô tả mã nguồn, logic kinh doanh, cấu trúc dữ liệu và dữ liệu tất cả đều được gắn kết với nhau - được bao bọc - trong một ngữ cảnh cụ thể. Như được minh họa trong Hình 6-4, các ngữ cảnh rành mạch xung quanh các dịch vụ và dữ liệu tương ứng của chúng giúp kiểm soát sự thay đổi, vì sự thay đổi chỉ giới hạn trong các dịch vụ đó trong ngữ cảnh rành mạch đó.

Thông thường, các ngữ cảnh giới hạn được hình thành xung quanh các dịch vụ và dữ liệu mà các dịch vụ sở hữu. Bằng "sở hữu", chúng tôi ý nói đến một dịch vụ có quyền ghi vào cơ sở dữ liệu (khác với việc chỉ có quyền truy cập đọc vào dữ liệu). Chúng tôi sẽ thảo luận về quyền sở hữu dữ liệu phân tán chi tiết hơn ở Chương 9.

Figure 6-4. Database changes are isolated to only those services within the associated bounded context

Lưu ý trong Hình 6-4 rằng Dịch vụ C cần truy cập một số dữ liệu trong Cơ sở dữ liệu D nằm trong một ngữ cảnh giới hạn với Dịch vụ D. Vì Cơ sở dữ liệu D nằm trong một ngữ cảnh giới hạn khác, Dịch vụ C không thể truy cập trực tiếp dữ liệu. Điều này không chỉ vi phạm quy tắc ngữ cảnh giới hạn, mà còn tạo ra sự lộn xộn liên quan đến việc kiểm soát thay đổi. Do đó, Dịch vụ C phải yêu cầu Dịch vụ D cung cấp dữ liệu. Có nhiều cách để truy cập dữ liệu mà dịch vụ không sở hữu trong khi vẫn duy trì ngữ cảnh giới hạn. Những kỹ thuật này sẽ được thảo luận chi tiết trong Chương 10.

Một khía cạnh quan trọng của một ngữ cảnh giới hạn liên quan đến kịch bản giữa Service C cần dữ liệu và Service D sở hữu dữ liệu đó trong ngữ cảnh giới hạn của nó là sự trừu tượng hóa cơ sở dữ liệu. Lưu ý rằng trong Hình 6-5, Service D đang truyền dữ liệu mà Service C đã yêu cầu thông qua một dạng hợp đồng nào đó (chẳng hạn như JSON, XML, hoặc có thể là một đối tượng).

Lợi thế của bối cảnh giới hạn là dữ liệu được gửi đến Service C có thể là một hợp đồng khác với sơ đồ của Database D. Điều này có nghĩa là một thay đổi phá vỡ đối với một bảng nào đó trong Database D chỉ ảnh hưởng đến Service D và không nhất thiết làm ảnh hưởng đến hợp đồng của dữ liệu được gửi đến Service C. Nói cách khác, Service C được trừu tượng hóa khỏi cấu trúc sơ đồ thực tế của Database D.

Figure 6-5. The contract from a service call abstracts the caller from the underlying database schema

Để minh họa sức mạnh của việc trừu tượng bối cảnh giới hạn này trong một kiến trúc phân tán, hãy giả định rằng Cơ sở dữ liệu D có một bảng Danh sách mong muốn với cấu trúc sau:

CREATE TABLE Wishlist ( CUSTOMER_ID VARCHAR(10), ITEM_ID VARCHAR(20), QUANTITY INT, EXPIRATION_DT DATE );

Hợp đồng JSON tương ứng mà Dịch vụ D gửi đến Dịch vụ C để yêu cầu các mục trong danh sách mong muốn như sau:

{ "$schema": "http://json-schema.org/draft-04/schema#", "properties": { "cust_id": {"type": "string"}, "item_id": {"type": "string"}, "qty": {"type": "number"}, "exp_dt": {"type": "number"} }, }

Lưu ý rằng trường dữ liệu ngày hết hạn (exp_dt) trong lược đồ JSON được đặt tên khác so với tên cột trong cơ sở dữ liệu và được chỉ định dưới dạng số (một giá trị dài đại diện cho thời gian epoch - số mili giây kể từ nửa đêm ngày 1 tháng 1 năm 1970), trong khi trong cơ sở dữ liệu nó được đại diện dưới dạng trường DATE. Bất kỳ thay đổi nào về tên cột hoặc loại cột trong cơ sở dữ liệu đều không còn ảnh hưởng đến Dịch vụ C vì có hợp đồng JSON riêng biệt.

Để minh họa cho điểm này, giả sử doanh nghiệp quyết định không còn hết hạn các mục trong danh sách ước muốn. Điều này đòi hỏi phải thay đổi cấu trúc bảng của cơ sở dữ liệu.

ALTER TABLE Wishlist DROP COLUMN EXPIRATION_DT;

Dịch vụ D sẽ phải được sửa đổi để phù hợp với sự thay đổi này vì nó nằm trong cùng một ngữ cảnh ràng buộc với cơ sở dữ liệu, nhưng hợp đồng tương ứng sẽ không cần phải thay đổi ngay lập tức. Cho đến khi hợp đồng cuối cùng được thay đổi, Dịch vụ D có thể chỉ định một ngày xa trong tương lai hoặc đặt giá trị thành zero để chỉ ra rằng sản phẩm không có hạn sử dụng. Điểm chính là Dịch vụ C được trừu tượng hóa khỏi những thay đổi đột phá được thực hiện với Cơ sở D do ngữ cảnh ràng buộc.

Connection management

Thiết lập kết nối đến cơ sở dữ liệu là một thao tác tốn kém. Một bộ kết nối cơ sở dữ liệu thường được sử dụng không chỉ để tăng hiệu suất mà còn để giới hạn số lượng kết nối đồng thời mà một ứng dụng được phép sử dụng. Trong các ứng dụng đơn khối, bộ kết nối cơ sở dữ liệu thường thuộc về ứng dụng (hoặc máy chủ ứng dụng). Tuy nhiên, trong các kiến trúc phân tán, mỗi dịch vụ—hay cụ thể hơn, mỗi phiên bản dịch vụ—thường có bộ kết nối riêng. Như được minh họa trong Hình 6-6, khi nhiều dịch vụ chia sẻ cùng một cơ sở dữ liệu, số lượng kết nối có thể nhanh chóng trở nên bão hòa, đặc biệt khi số lượng dịch vụ hoặc phiên bản dịch vụ tăng lên.

Figure 6-6. Database connections can quickly get saturated with multiple service instances

Việc đạt (hoặc vượt) số lượng kết nối cơ sở dữ liệu tối đa có sẵn là một yếu tố khác cần xem xét khi quyết định có nên tách rời cơ sở dữ liệu hay không. Thời gian chờ kết nối (thời gian chờ để có được một kết nối có sẵn) thường là dấu hiệu đầu tiên cho thấy số lượng kết nối cơ sở dữ liệu tối đa đã được đạt đến. Vì thời gian chờ kết nối cũng có thể biểu hiện dưới dạng thời gian yêu cầu hết hạn hoặc các cầu dao bị ngắt, việc tìm kiếm thời gian chờ kết nối thường là điều đầu tiên chúng tôi khuyên bạn nên làm nếu những điều kiện này thường xuyên xảy ra khi sử dụng một cơ sở dữ liệu chung.

Để minh họa các vấn đề liên quan đến kết nối cơ sở dữ liệu và kiến trúc phân tán, hãy xem xét ví dụ sau: một ứng dụng đơn thể với 200 kết nối cơ sở dữ liệu được chia thành một kiến trúc phân tán gồm 50 dịch vụ, mỗi dịch vụ có 10 kết nối cơ sở dữ liệu trong hồ bơi kết nối của nó.

Ứng dụng monolithic gốc	200 kết nối
Dịch vụ phân tán	50
Kết nối cho mỗi dịch vụ	10
Số lượng cài đặt dịch vụ tối thiểu	2
Tổng số kết nối dịch vụ	một nghìn

Chú ý rằng số lượng kết nối cơ sở dữ liệu trong cùng một ngữ cảnh ứng dụng đã tăng từ 200 lên 1,000, và các dịch vụ còn chưa bắt đầu mở rộng! Giả sử một nửa các dịch vụ mở rộng lên trung bình 5 phiên bản mỗi cái, số lượng kết nối cơ sở dữ liệu nhanh chóng tăng lên 1,700.

Nếu không có một chiến lược kết nối hoặc kế hoạch quản trị nào đó, các dịch vụ sẽ cố gắng sử dụng nhiều kết nối nhất có thể, thường xuyên gây ra tình trạng thiếu kết nối cho các dịch vụ khác đang cần. Vì lý do này, việc quản lý cách sử dụng kết nối cơ sở dữ liệu trong kiến trúc phân tán là rất quan trọng. Một phương pháp hiệu quả là phân bổ cho từng dịch vụ một hạn mức kết nối để quản lý sự phân phối các kết nối cơ sở dữ liệu có sẵn giữa các dịch vụ. Hạn mức kết nối xác định số lượng kết nối cơ sở dữ liệu tối đa mà một dịch vụ được phép sử dụng hoặc cung cấp trong bể kết nối của nó.

Bằng cách chỉ định một hạn ngạch kết nối, các dịch vụ sẽ không được phép tạo ra nhiều kết nối cơ sở dữ liệu hơn số lượng đã được phân bổ cho nó. Nếu một dịch vụ đạt đến số lượng kết nối cơ sở dữ liệu tối đa trong hạn ngạch của nó, nó phải chờ cho một trong các kết nối mà nó đang sử dụng trở nên khả dụng. Phương pháp này có thể được thực hiện bằng hai cách: phân phối đều hạn ngạch kết nối giống nhau cho mỗi dịch vụ, hoặc phân bổ một hạn ngạch kết nối khác nhau cho mỗi dịch vụ dựa trên nhu cầu của nó.

Cách tiếp cận phân phối đồng đều thường được sử dụng khi lần đầu triển khai dịch vụ, và chưa biết được mỗi dịch vụ sẽ cần bao nhiêu kết nối trong hoạt động bình thường và cao điểm. Mặc dù đơn giản, cách tiếp cận này không hiệu quả lắm vì một số dịch vụ có thể cần nhiều kết nối hơn so với những dịch vụ khác, trong khi một số kết nối do các dịch vụ khác giữ có thể không được sử dụng.

Mặc dù phức tạp hơn, phương pháp phân phối biến động là hiệu quả hơn nhiều trong việc quản lý các kết nối cơ sở dữ liệu đến một cơ sở dữ liệu chung. Với phương pháp này, mỗi dịch vụ được chỉ định một hạn ngạch kết nối khác nhau dựa trên tính năng và yêu cầu khả năng mở rộng của nó. Lợi ích của phương pháp này là tối ưu hóa việc sử dụng các kết nối cơ sở dữ liệu có sẵn trên các dịch vụ phân tán, đảm bảo rằng những dịch vụ cần nhiều kết nối cơ sở dữ liệu hơn có chúng sẵn sàng để sử dụng. Tuy nhiên, nhược điểm là nó cần có kiến thức về bản chất của tính năng và yêu cầu khả năng mở rộng của từng dịch vụ.

Chúng tôi thường khuyên bạn nên bắt đầu với phương pháp phân phối đồng đều và tạo các hàm fitness để đo lường mức sử dụng kết nối đồng thời cho mỗi dịch vụ. Chúng tôi cũng khuyến nghị giữ các giá trị hạn ngạch kết nối trong một máy chủ (hoặc dịch vụ) cấu hình bên ngoài để các giá trị có thể dễ dàng điều chỉnh hoặc thủ công hoặc lập trình thông qua các thuật toán học máy đơn giản. Kỹ thuật này không chỉ giúp giảm thiểu nguy cơ bão hòa kết nối mà còn cân bằng hợp lý các kết nối cơ sở dữ liệu có sẵn giữa các dịch vụ phân tán để đảm bảo rằng không có kết nối nhàn rỗi nào bị lãng phí.

Bảng 6-1 cho thấy một ví dụ về việc bắt đầu sử dụng phương pháp phân phối đều cho một cơ sở dữ liệu có thể hỗ trợ tối đa 100 kết nối đồng thời. Lưu ý rằng Dịch vụ A chỉ bao giờ cần tối đa 5 kết nối, Dịch vụ C chỉ cần 15 kết nối và Dịch vụ E chỉ cần 14 kết nối, trong khi Dịch vụ B và Dịch vụ D đã đạt giới hạn kết nối tối đa của chúng và đã trải qua thời gian chờ kết nối.

Table 6-1. Connection quota allocations evenly distributed

	Service	Quota	Max used	Waits
	A	20	5	Không
→	B	20	20	Có
	C	20	15	Không
→	D	20	20	Có
	E	20	14	Không

Vì Service A đang thấp hơn hạn mức kết nối của nó, đây là một địa điểm tốt để bắt đầu phân bổ lại các kết nối cho các dịch vụ khác. Di chuyển năm kết nối cơ sở dữ liệu đến Service B và năm kết nối cơ sở dữ liệu đến Service D đem lại kết quả như được trình bày trong Bảng 6-2.

Table 6-2. Connection quota allocations with varying distributions

	Service	Quota	Max used	Waits
	A	10	5	Không
→	B	25	25	Có
	C	20	15	Không
	D	25	25	Không
	E	20	14	Không

Điều này đã tốt hơn, nhưng Dịch vụ B vẫn gặp phải tình trạng chờ kết nối, cho thấy rằng nó cần nhiều kết nối hơn mức cho phép trong hạn ngạch kết nối của nó. Việc điều chỉnh lại các hạn ngạch một cách thậm chí còn sâu hơn bằng cách lấy hai kết nối từ Dịch vụ A và Dịch vụ E mang lại kết quả tốt hơn nhiều, như được thể hiện trong Bảng 6-3.

Table 6-3. Further connection quota tuning results in no connection waits

Service	Quota	Max used	Waits
A	8	5	Không
B	29	27	Không
C	20	15	Không
D	25	25	Không
E	18	14	Không

Phân tích này, có thể được rút ra từ các hàm fitness liên tục thu thập dữ liệu thông số đã được phát trực tiếp từ mỗi dịch vụ, cũng có thể được sử dụng để xác định mức độ gần gũi giữa số lượng kết nối tối đa đã sử dụng và số lượng kết nối tối đa có sẵn, cũng như lượng bộ đệm tồn tại cho mỗi dịch vụ về hạn ngạch và số kết nối tối đa đã sử dụng.

Scalability

Một trong những lợi thế của kiến trúc phân tán là khả năng mở rộng - khả năng cho các dịch vụ xử lý sự gia tăng về khối lượng yêu cầu trong khi vẫn duy trì thời gian phản hồi nhất quán. Hầu hết các sản phẩm liên quan đến cơ sở hạ tầng trên đám mây và tại chỗ đều làm tốt trong việc đảm bảo rằng các dịch vụ, container, máy chủ HTTP và máy ảo có thể mở rộng để đáp ứng sự gia tăng nhu cầu. Nhưng còn cơ sở dữ liệu thì sao?

Như được minh họa trong Hình 6-7, khả năng mở rộng dịch vụ có thể gây áp lực lớn lên cơ sở dữ liệu, không chỉ về số lượng kết nối cơ sở dữ liệu (như đã thảo luận ở phần trước), mà còn về thông lượng và khả năng lưu trữ của cơ sở dữ liệu. Để một hệ thống phân tán có thể mở rộng, tất cả các phần của hệ thống cần phải mở rộng, bao gồm cả cơ sở dữ liệu.

Figure 6-7. The database must also scale when services scale

Khả năng mở rộng là một yếu tố khác cần xem xét khi nghĩ đến việc tách một cơ sở dữ liệu. Kết nối cơ sở dữ liệu, dung lượng, thông lượng và hiệu suất đều là những yếu tố trong việc xác định liệu một cơ sở dữ liệu chia sẻ có thể đáp ứng các yêu cầu của nhiều dịch vụ trong một kiến trúc phân tán hay không.

Xem xét các hạn ngạch kết nối cơ sở dữ liệu đã tinh chỉnh trong Bảng 6-3 ở phần trước. Khi các dịch vụ mở rộng bằng cách thêm nhiều phiên bản, bức tranh thay đổi một cách rõ rệt, như được thể hiện trong Bảng 6-4, nơi tổng số kết nối cơ sở dữ liệu là 100.

Table 6-4. When services scale, more connection are used than are available

Service	Quota	Max used	Instances	Total used
A	8	5	2	10
B	29	27	3	81
C	20	15	3	45
D	25	25	2	50
E	18	14	4	56
TỔNG CỘNG	100	86	14	242

Xin lưu ý rằng mặc dù hạn ngạch kết nối được phân bổ để phù hợp với 100 kết nối cơ sở dữ liệu có sẵn, nhưng khi các dịch vụ bắt đầu mở rộng, hạn ngạch không còn hợp lệ vì tổng số kết nối được sử dụng tăng lên 242, tức là nhiều hơn 142 kết nối so với số lượng có sẵn trong cơ sở dữ liệu. Điều này có khả năng dẫn đến việc chờ kết nối, từ đó sẽ gây ra suy giảm hiệu suất tổng thể và thời gian chờ của yêu cầu.

Việc chia nhỏ dữ liệu thành các miền dữ liệu riêng biệt hoặc thậm chí một cơ sở dữ liệu cho mỗi dịch vụ, như được minh họa trong Hình 6-8, yêu cầu ít kết nối đến từng cơ sở dữ liệu hơn, từ đó cung cấp khả năng mở rộng và hiệu suất cơ sở dữ liệu tốt hơn khi các dịch vụ phát triển.

Figure 6-8. Breaking apart the database provides better database scalability

Ngoài kết nối cơ sở dữ liệu, một yếu tố cần xem xét liên quan đến khả năng mở rộng là tải trọng đặt lên cơ sở dữ liệu. Bằng cách chia tách một cơ sở dữ liệu, tải trọng đặt lên mỗi cơ sở dữ liệu sẽ giảm, do đó cũng cải thiện hiệu suất tổng thể và khả năng mở rộng.

Fault tolerance

Khi nhiều dịch vụ chia sẻ cùng một cơ sở dữ liệu, hệ thống tổng thể trở nên kém khả năng chịu lỗi hơn vì cơ sở dữ liệu trở thành một điểm lỗi duy nhất (SPOF). Ở đây, chúng tôi định nghĩa khả năng chịu lỗi là khả năng của một số phần của hệ thống tiếp tục hoạt động không bị gián đoạn khi một dịch vụ hoặc cơ sở dữ liệu gặp sự cố. Lưu ý trong Hình 6-9 rằng khi chia sẻ một cơ sở dữ liệu duy nhất, khả năng chịu lỗi tổng thể là thấp vì nếu cơ sở dữ liệu bị ngừng hoạt động, tất cả các dịch vụ trở nên không hoạt động.

Figure 6-9. If the database goes down, all services become nonoperational

Tính chịu lỗi là một động lực khác để xem xét việc tách rời dữ liệu. Nếu tính chịu lỗi được yêu cầu cho một số phần của hệ thống, việc tách rời dữ liệu có thể loại bỏ điểm thất bại duy nhất trong hệ thống, như được trình bày trong Hình 6-10. Điều này đảm bảo rằng một số phần của hệ thống vẫn hoạt động dù có sự cố xảy ra với cơ sở dữ liệu.

Figure 6-10. Breaking apart the database achieves better fault tolerance

Lưu ý rằng kể từ khi dữ liệu được tách rời, nếu Cơ sở dữ liệu B gặp sự cố, chỉ có Dịch vụ B và Dịch vụ C bị ảnh hưởng và không hoạt động, trong khi các dịch vụ khác tiếp tục hoạt động không bị gián đoạn.

Architectural quantum

Nhớ lại từ Chương 2 rằng một lượng kiến trúc được định nghĩa là một hiện vật có thể triển khai độc lập với sự kết nối chức năng cao, kết nối tĩnh cao và kết nối động đồng bộ. Lượng kiến trúc giúp cung cấp hướng dẫn về thời điểm cần tách rời một cơ sở dữ liệu, làm cho nó trở thành một yếu tố thúc đẩy phân tán dữ liệu khác.

Xem xét các dịch vụ trong Hình 6-11, nơi Dịch vụ A và Dịch vụ B yêu cầu các đặc điểm kiến trúc khác với các dịch vụ khác. Lưu ý trong sơ đồ rằng mặc dù Dịch vụ A và Dịch vụ B được nhóm lại với nhau, nhưng chúng không tạo thành một thực thể kiến trúc riêng biệt so với các dịch vụ khác do cùng chia sẻ một cơ sở dữ liệu. Do đó, cả năm dịch vụ, cùng với cơ sở dữ liệu, tạo thành một thực thể kiến trúc duy nhất.

Figure 6-11. The database is part of the architectural quantum

Vì cơ sở dữ liệu được đưa vào phần sự kết hợp chức năng của định nghĩa kiến trúc quantum, nên cần phải tách dữ liệu ra để mỗi phần kết quả có thể nằm trong quantum riêng của nó. Lưu ý trong Hình 6-12 rằng, do cơ sở dữ liệu bị tách ra, Dịch vụ A và Dịch vụ B, cùng với dữ liệu tương ứng, hiện nay nằm trong một quantum riêng biệt so với quantum được hình thành với các dịch vụ C, D và E.

Figure 6-12. Breaking up the database forms two architectural quanta

Data Integrators

Các trình tích hợp dữ liệu thực hiện điều hoàn toàn ngược lại so với các trình phân tách dữ liệu đã được thảo luận ở phần trước. Những yếu tố này cung cấp câu trả lời và lý do cho câu hỏi "Khi nào tôi nên xem xét việc kết hợp dữ liệu trở lại?" Cùng với các trình phân tách dữ liệu, các trình tích hợp dữ liệu cung cấp sự cân bằng và các sự đánh đổi khi phân tích khi nào nên tách rời dữ liệu và khi nào không nên.

Hai động lực tích hợp chính để gộp dữ liệu lại với nhau là:

Data relationships

Có khóa ngoại, trigger hay view nào hình thành mối quan hệ chặt chẽ giữa các bảng không?

Database transactions

Một đơn vị công việc giao dịch đơn lẻ có cần thiết để đảm bảo tính toàn vẹn và nhất quán của dữ liệu không?

Mỗi trình điều khiển tích hợp này sẽ được thảo luận chi tiết trong các phần tiếp theo.

Data relationships

Giống như các thành phần trong một kiến trúc, các bảng cơ sở dữ liệu cũng có thể được kết hợp, đặc biệt là đối với các cơ sở dữ liệu quan hệ. Các đối tượng như khóa ngoại, trigger, view và thủ tục lưu trữ liên kết các bảng lại với nhau, làm cho việc tách dữ liệu trở nên khó khăn; xem Hình 6-13.

Hãy tưởng tượng bạn tiếp cận DBA hoặc kiến trúc sư dữ liệu của mình và nói với họ rằng vì cơ sở dữ liệu cần phải được phân tách để hỗ trợ các bối cảnh biên chặt chẽ trong một hệ sinh thái microservices, mọi khóa ngoại và chế độ xem trong cơ sở dữ liệu cần phải bị loại bỏ! Đó không phải là một kịch bản khả thi (hoặc thậm chí hợp lý), nhưng đó chính xác là những gì sẽ cần diễn ra để hỗ trợ mô hình cơ sở dữ liệu-theo-dịch vụ trong microservices.

Figure 6-13. Foreign keys (FK), triggers, and views create tightly coupled relationships between data

Những artefact này là cần thiết trong hầu hết các cơ sở dữ liệu quan hệ để hỗ trợ tính nhất quán và tính toàn vẹn của dữ liệu. Ngoài những artefact vật lý này, dữ liệu cũng có thể có mối quan hệ logic, chẳng hạn như bảng vé vấn đề và bảng trạng thái vé vấn đề tương ứng của nó. Tuy nhiên, như minh họa trong Hình 6-14, những artefact này phải được loại bỏ khi di chuyển dữ liệu sang một lược đồ hoặc cơ sở dữ liệu khác để hình thành các ngữ cảnh bó hẹp.

Figure 6-14. Data artifacts must be removed when breaking apart data

Lưu ý rằng mối quan hệ khóa ngoại (FK) giữa các bảng trong Dịch vụ A có thể được giữ nguyên vì dữ liệu nằm trong cùng một bối cảnh ràng buộc, sơ đồ hoặc cơ sở dữ liệu. Tuy nhiên, các khóa ngoại (FK) giữa các bảng trong Dịch vụ B và Dịch vụ C phải được loại bỏ (cũng như view được sử dụng trong Dịch vụ C) vì những bảng đó liên kết với các cơ sở dữ liệu hoặc sơ đồ khác nhau.

Mối quan hệ giữa dữ liệu, dù là logic hay vật lý, là một động lực tích hợp dữ liệu, do đó tạo ra sự đánh đổi giữa các tác nhân phân tách dữ liệu và các tác nhân tích hợp dữ liệu. Chẳng hạn, việc kiểm soát thay đổi (một tác nhân phân tách dữ liệu) có quan trọng hơn việc bảo tồn các mối quan hệ khóa ngoại giữa các bảng (một tác nhân tích hợp dữ liệu) không? Sự chống chịu lỗi (một tác nhân phân tách dữ liệu) có quan trọng hơn việc bảo tồn các view vật liệu giữa các bảng (một tác nhân tích hợp dữ liệu) không? Việc xác định điều gì quan trọng hơn giúp đưa ra quyết định về việc liệu dữ liệu có nên được tách ra hay không và độ chi tiết của schema kết quả nên như thế nào.

Database transactions

Một bộ tích hợp dữ liệu khác là giao dịch cơ sở dữ liệu, một điều chúng tôi thảo luận chi tiết trong “Giao dịch phân tán”. Như được thể hiện trong Hình 6-15, khi một dịch vụ đơn lẻ thực hiện nhiều hành động ghi cơ sở dữ liệu vào các bảng riêng biệt trong cùng một cơ sở dữ liệu hoặc lược đồ, những cập nhật đó có thể được thực hiện trong một giao dịch Atomicity, Consistency, Isolation, Durability (ACID) và được xác nhận hoặc hoàn tác như một đơn vị công việc duy nhất.

Figure 6-15. A single transactional unit of work exists when the data is together

Tuy nhiên, khi dữ liệu được phân tách thành các sơ đồ hoặc cơ sở dữ liệu riêng biệt, như được minh họa trong Hình 6-16, một đơn vị giao dịch duy nhất không còn tồn tại nữa do các cuộc gọi từ xa giữa các dịch vụ. Điều này có nghĩa là một thao tác chèn hoặc cập nhật có thể được cam kết trong một bảng, nhưng không trong các bảng khác do các điều kiện lỗi, dẫn đến các vấn đề về tính nhất quán và tính toàn vẹn của dữ liệu.

Figure 6-16. Single unit of work transactions don’t exist when data is broken apart

Trong khi chúng ta đi sâu vào các chi tiết về quản lý giao dịch phân tán và các saga giao dịch trong Chương 12, điểm ở đây là nhấn mạnh rằng giao dịch cơ sở dữ liệu là một yếu tố tích hợp dữ liệu khác và cần được xem xét khi cân nhắc việc tách rời một cơ sở dữ liệu.

Sysops Squad Saga: Justifying Database Decomposition

Thứ Hai, ngày 15 tháng 11, 15:55

Được trang bị những lý do của họ, Addison và Devon đã gặp nhau để thuyết phục Dana rằng việc tách rời cơ sở dữ liệu Sysops Squad đơn nhất là cần thiết.

“Chào, Dana,” Addison nói. “Chúng tôi nghĩ rằng chúng tôi có đủ chứng cứ để thuyết phục bạn rằng cần phải tách rời cơ sở dữ liệu của đội Sysops Squad.”

“Em đang lắng nghe,” Dana nói, hai tay khoanh lại và sẵn sàng tranh luận rằng cơ sở dữ liệu nên giữ nguyên như hiện tại.

“Em sẽ bắt đầu,” Addison nói. “Chú ý rằng những bản ghi này liên tục cho thấy mỗi khi các báo cáo hoạt động chạy, chức năng ghi vé trong ứng dụng bị đơ?”

“Vâng,” Dana nói, “Tôi thừa nhận rằng ngay cả tôi cũng nghi ngờ điều đó. Rõ ràng là có điều gì đó sai với cách mà chức năng đặt vé truy cập vào cơ sở dữ liệu, không phải báo cáo.”

“Thực ra,” Addison nói, “đó là sự kết hợp của cả việc bán vé và báo cáo. Nhìn đây.”

Addison đã cho Dana xem các chỉ số và nhật ký cho thấy một số truy vấn buộc phải được bao bọc trong các luồng, và rằng các truy vấn từ chức năng đặt vé đã bị hết thời gian chờ do trạng thái chờ khi các truy vấn báo cáo được thực thi. Addison cũng đã chỉ cho cách phần báo cáo của hệ thống sử dụng các luồng song song để truy vấn các phần của các báo cáo phức tạp cùng một lúc, về cơ bản chiếm hết tất cả các kết nối cơ sở dữ liệu.

“Được rồi, tôi có thể thấy cách việc có một cơ sở dữ liệu báo cáo riêng sẽ giúp tình hình từ góc độ kết nối cơ sở dữ liệu. Nhưng điều đó vẫn không thuyết phục tôi rằng dữ liệu không báo cáo nên được tách rời,” Dana nói.

“Nhắc đến kết nối cơ sở dữ liệu,” Devon nói, “hãy nhìn vào ước lượng kết nối pool này khi chúng ta bắt đầu tách rời các dịch vụ miền.”

Devon đã chỉ cho Dana số lượng dịch vụ ước tính trong ứng dụng phân phối Sysops Squad cuối cùng, bao gồm số lượng phiên bản được dự kiến cho mỗi dịch vụ khi ứng dụng mở rộng. Dana đã giải thích cho Devon rằng pool kết nối được chứa trong mỗi phiên bản dịch vụ riêng biệt, không giống như trong giai đoạn hiện tại của quá trình di chuyển, nơi mà máy chủ ứng dụng sở hữu pool kết nối.

“Vì vậy, bạn thấy đấy, Dana,” Devon nói, “với những ước lượng dự kiến này, chúng ta sẽ cần thêm 2.000 kết nối đến cơ sở dữ liệu để cung cấp khả năng mở rộng mà chúng ta cần để xử lý lượng vé, và chúng ta đơn giản là không có đủ với một cơ sở dữ liệu duy nhất.”

"Dana đã dành một chút thời gian để nhìn qua các con số. 'Bạn có đồng ý với những con số này không, Addison?'"

“Tôi có,” Addison nói. “Devon và tôi đã tự mình nghĩ ra chúng sau nhiều phân tích dựa trên lượng lưu lượng HTTP cũng như tỷ lệ tăng trưởng dự kiến được Parker cung cấp.”

“Tôi phải thừa nhận,” Dana nói, “đây là những thứ tốt mà hai bạn đã chuẩn bị. Tôi đặc biệt thích việc các bạn đã suy nghĩ về việc không để các dịch vụ kết nối với nhiều cơ sở dữ liệu hoặc lược đồ. Như các bạn biết, trong cuốn sách của tôi, điều đó là không chấp nhận.”

“Chúng tôi cũng vậy. Tuy nhiên, chúng tôi có một lý do nữa để nói chuyện với bạn,” Addison nói. “Như bạn có thể biết hoặc không biết, chúng tôi đã gặp rất nhiều vấn đề liên quan đến việc hệ thống không khả dụng cho khách hàng của chúng tôi. Mặc dù việc tách rời các dịch vụ mang lại cho chúng tôi một mức độ chống lỗi nào đó, nhưng nếu một cơ sở dữ liệu đơn thể bị ngừng hoạt động do bảo trì hoặc do sự cố máy chủ, tất cả các dịch vụ sẽ trở thành không hoạt động.”

"Devon thêm vào, 'Điều Addison đang nói là bằng cách tách rời cơ sở dữ liệu, chúng ta có thể cung cấp khả năng chịu lỗi tốt hơn bằng cách tạo ra các silo miền cho dữ liệu. Nói cách khác, nếu cơ sở dữ liệu khảo sát gặp sự cố, chức năng bán vé vẫn sẽ có sẵn.'"

“Chúng tôi gọi đó là một quantum kiến trúc,” Addison nói. “Nói cách khác, vì cơ sở dữ liệu là một phần của việc liên kết tĩnh của một hệ thống, việc tách nó ra sẽ khiến chức năng đặt vé cốt lõi trở thành độc lập và không phụ thuộc đồng thời vào các phần khác của hệ thống.”

“Nghe này,” Dana nói, “bạn đã thuyết phục tôi rằng có lý do chính đáng để tách rời cơ sở dữ liệu của đội Sysops, nhưng hãy giải thích cho tôi cách mà bạn có thể nghĩ tới việc làm điều đó. Bạn có nhận ra có bao nhiêu khóa ngoại và view trong cơ sở dữ liệu đó không? Không có cách nào bạn có thể loại bỏ tất cả những thứ đó.”

"Chúng ta không nhất thiết phải loại bỏ tất cả những hiện vật đó. Đó là lý do tại sao các miền dữ liệu và quy trình năm bước lại quan trọng," Devon nói. "Để tôi giải thích..."

Step 1: Analyze Database and Create Data Domains

Như minh họa trong Hình 6-20, tất cả các dịch vụ đều có quyền truy cập vào tất cả dữ liệu trong cơ sở dữ liệu. Thực hành này, được gọi là phong cách tích hợp cơ sở dữ liệu chia sẻ mà Gregor Hohpe và Bobby Woolf mô tả trong cuốn sách Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley), tạo ra một sự kết nối chặt chẽ giữa dữ liệu và các dịch vụ truy cập dữ liệu đó. Như đã thảo luận trong “Các yếu tố phân tách dữ liệu”, sự kết nối chặt chẽ này trong cơ sở dữ liệu làm cho việc quản lý thay đổi trở nên rất khó khăn.

Figure 6-20. Multiple services use the same database, accessing all the tables necessary for read or write purposes

Bước đầu tiên trong việc phân chia cơ sở dữ liệu là xác định các nhóm miền cụ thể trong cơ sở dữ liệu. Ví dụ, như được thể hiện trong Bảng 6-5, các bảng liên quan được nhóm lại với nhau để giúp xác định các miền dữ liệu có thể có.

Step 2: Assign Tables to Data Domains

Bước tiếp theo là nhóm các bảng theo một ngữ cảnh giới hạn cụ thể, phân bổ các bảng thuộc về một miền dữ liệu cụ thể vào lược đồ riêng của chúng. Lược đồ là một cấu trúc logic trong các máy chủ cơ sở dữ liệu. Lược đồ chứa các đối tượng như bảng, chế độ xem, hàm, v.v. Trong một số máy chủ cơ sở dữ liệu, như Oracle, lược đồ là giống như người dùng, trong khi ở các cơ sở dữ liệu khác, như SQL Server, lược đồ là không gian logic cho các đối tượng cơ sở dữ liệu nơi người dùng có quyền truy cập vào các lược đồ này.

Như được minh họa trong Hình 6-21, chúng tôi đã tạo ra các sơ đồ cho mỗi miền dữ liệu và di chuyển các bảng đến các sơ đồ mà chúng thuộc về.

Figure 6-21. Services use the primary schema according to their data domain needs

Khi các bảng thuộc các miền dữ liệu khác nhau được kết nối chặt chẽ và liên quan đến nhau, các miền dữ liệu phải được kết hợp, tạo ra một ngữ cảnh có giới hạn rộng hơn mà nhiều dịch vụ sở hữu một miền dữ liệu cụ thể. Việc kết hợp các miền dữ liệu sẽ được thảo luận chi tiết hơn trong Chương 9.

Để minh hoạ việc gán bảng cho các lược đồ, hãy xem xét ví dụ về Đội Sysops, trong đó bảng thanh toán phải được chuyển từ lược đồ gốc của nó sang một lược đồ miền dữ liệu khác gọi là thanh toán.

ALTER SCHEMA payment TRANSFER sysops.billing;

Ngoài ra, một nhóm cơ sở dữ liệu có thể tạo ra các từ đồng nghĩa cho các bảng không thuộc về lược đồ của họ. Từ đồng nghĩa là các cấu trúc trong cơ sở dữ liệu, tương tự như liên kết tượng trưng, cung cấp một tên thay thế cho một đối tượng cơ sở dữ liệu khác có thể tồn tại trong cùng một lược đồ hoặc lược đồ khác hoặc máy chủ khác. Mặc dù ý tưởng của từ đồng nghĩa là nhằm loại bỏ các truy vấn giữa các lược đồ, nhưng quyền đọc hoặc ghi cần thiết để truy cập vào chúng.

Để minh họa cho thực tiễn này, hãy xem xét truy vấn đa miền sau đây:

SELECT history.ticket_id, history.notes, agent.name FROM ticket.ticket_history AS history INNER JOIN profile.sysops_user AS agent ON ( history.assigned_to_sysops_user_id = agent.sysops_user_id )

Tiếp theo, tạo một từ đồng nghĩa cho bảng profile.sysops_user trong schema ticketing:

CREATE SYNONYM ticketing.sysops_user FOR profile.sysops_user; GO

Do đó, truy vấn có thể tận dụng từ đồng nghĩa sysops_user thay vì bảng liên miền:

SELECT history.ticket_id, history.notes, agent.name FROM ticket.ticket_history AS history INNER JOIN ticket.sysops_user AS agent ON ( history.assigned_to_sysops_user_id = agent.sysops_user_id )

Rất tiếc, việc tạo các từ đồng nghĩa theo cách này cho các bảng được truy cập qua các schema cung cấp cho các nhà phát triển ứng dụng những điểm gộp. Để hình thành các miền dữ liệu thích hợp, những điểm gộp này cần phải được tách rời tại một thời điểm nào đó trong tương lai, do đó chuyển các điểm tích hợp từ lớp cơ sở dữ liệu sang lớp ứng dụng.

Mặc dù từ đồng nghĩa không thực sự loại bỏ các truy vấn chéo giữa các sơ đồ, nhưng chúng cho phép kiểm tra phụ thuộc và phân tích mã dễ dàng hơn, giúp việc tách chúng ra sau này trở nên dễ dàng hơn.

Step 3: Separate Database Connections to Data Domains

Trong bước này, logic kết nối cơ sở dữ liệu trong mỗi dịch vụ được tái cấu trúc để đảm bảo các dịch vụ kết nối với một sơ đồ cụ thể và có quyền đọc và ghi chỉ đối với các bảng thuộc về miền dữ liệu của chúng. Sự chuyển đổi này, được minh họa trong Hình 6-22, là khó khăn nhất vì tất cả việc truy cập đa sơ đồ phải được giải quyết ở cấp độ dịch vụ.

Lưu ý rằng cấu hình cơ sở dữ liệu đã được thay đổi để tất cả việc truy cập dữ liệu được thực hiện nghiêm ngặt thông qua các dịch vụ và các lược đồ kết nối của chúng. Trong ví dụ này, Dịch vụ C giao tiếp với Dịch vụ D chứ không phải với Lược đồ D. Không có truy cập chéo giữa các lược đồ; tất cả các đồng nghĩa được tạo trong "Bước 2: Gán Bảng vào miền Dữ liệu" đều bị xóa.

Figure 6-22. Move the cross-schema object access to the services, away from direct cross-schema access

Tip

Khi cần dữ liệu từ các lĩnh vực khác, đừng truy cập vào cơ sở dữ liệu của họ. Thay vào đó, hãy truy cập chúng thông qua dịch vụ sở hữu miền dữ liệu.

Sau khi hoàn thành bước này, cơ sở dữ liệu sẽ ở trạng thái chủ quyền dữ liệu theo dịch vụ, điều này xảy ra khi mỗi dịch vụ sở hữu dữ liệu của chính nó. Chủ quyền dữ liệu theo dịch vụ là trạng thái lý tưởng cho một kiến trúc phân tán. Giống như tất cả các thực hành trong kiến trúc, nó bao gồm lợi ích và nhược điểm:

Benefits

• Các nhóm có thể thay đổi sơ đồ cơ sở dữ liệu mà không cần lo lắng về việc ảnh hưởng đến các thay đổi ở các miền khác.

• Mỗi dịch vụ có thể sử dụng công nghệ cơ sở dữ liệu và loại cơ sở dữ liệu phù hợp nhất với trường hợp sử dụng của họ.

Shortcomings

• Các vấn đề về hiệu suất xảy ra khi các dịch vụ cần truy cập vào một khối lượng dữ liệu lớn.

• Tính toàn vẹn tham chiếu không thể được duy trì trong cơ sở dữ liệu, dẫn đến khả năng chất lượng dữ liệu kém.

• Tất cả mã cơ sở dữ liệu (thủ tục lưu trữ, hàm) truy cập các bảng thuộc về các miền khác phải được chuyển đến lớp dịch vụ.

Step 4: Move Schemas to Separate Database Servers

Khi các đội cơ sở dữ liệu đã tạo ra và phân tách các miền dữ liệu, và đã cô lập các dịch vụ để chúng truy cập vào dữ liệu của riêng mình, họ có thể di chuyển các miền dữ liệu đến các cơ sở dữ liệu vật lý riêng biệt. Đây thường là một bước cần thiết vì ngay cả khi các dịch vụ truy cập vào các lược đồ của chúng, việc truy cập một cơ sở dữ liệu duy nhất tạo ra một lượng kiến trúc duy nhất, như đã đề cập trong Chương 2, điều này có thể có ảnh hưởng xấu đến các đặc điểm hoạt động, chẳng hạn như khả năng mở rộng, khả năng chịu lỗi và hiệu suất.

Khi chuyển các lược đồ đến các cơ sở dữ liệu vật lý riêng biệt, các nhóm cơ sở dữ liệu có hai lựa chọn: sao lưu và phục hồi, hoặc sao chép. Các tùy chọn này được trình bày như sau:

Backup and restore

Với tùy chọn này, các nhóm trước tiên sao lưu mỗi schema với các miền dữ liệu, sau đó thiết lập máy chủ cơ sở dữ liệu cho mỗi miền dữ liệu. Họ sau đó phục hồi các schema, kết nối các dịch vụ với các schema trong các máy chủ cơ sở dữ liệu mới, và cuối cùng xóa các schema khỏi máy chủ cơ sở dữ liệu ban đầu. Cách tiếp cận này thường yêu cầu thời gian ngừng hoạt động cho quá trình di chuyển.

Replicate

Sử dụng tùy chọn sao chép, các nhóm trước tiên thiết lập các máy chủ cơ sở dữ liệu cho mỗi miền dữ liệu. Tiếp theo, họ sao chép các schema, chuyển kết nối sang các máy chủ cơ sở dữ liệu mới, và sau đó xóa các schema khỏi máy chủ cơ sở dữ liệu gốc. Mặc dù phương pháp này tránh được thời gian ngừng hoạt động, nhưng nó đòi hỏi nhiều công việc hơn để thiết lập việc sao chép và quản lý sự phối hợp tăng lên.

Hình 6-23 cho thấy một ví dụ về tùy chọn sao chép, trong đó đội ngũ cơ sở dữ liệu thiết lập nhiều máy chủ cơ sở dữ liệu để có một máy chủ cơ sở dữ liệu cho mỗi miền dữ liệu.

Figure 6-23. Replicate schemas (data domains) to their own database servers

Step 5: Switch Over to Independent Database Servers

Khi các lược đồ đã được sao chép hoàn toàn, các kết nối dịch vụ có thể được chuyển đổi. Bước cuối cùng trong việc làm cho các miền dữ liệu và dịch vụ hoạt động như những đơn vị triển khai độc lập của riêng chúng là loại bỏ kết nối với các máy chủ cơ sở dữ liệu cũ và xóa các lược đồ khỏi các máy chủ cơ sở dữ liệu cũ. Trạng thái cuối cùng được thấy trong Hình 6-24.

Figure 6-24. Independent database servers for each data domain

Khi nhóm cơ sở dữ liệu đã phân tách các miền dữ liệu, cô lập các kết nối cơ sở dữ liệu và cuối cùng chuyển các miền dữ liệu sang các máy chủ cơ sở dữ liệu riêng biệt, họ có thể tối ưu hóa từng máy chủ cơ sở dữ liệu cho tính khả dụng và khả năng mở rộng. Các đội cũng có thể phân tích dữ liệu để xác định loại cơ sở dữ liệu phù hợp nhất để sử dụng, giới thiệu việc sử dụng nhiều loại cơ sở dữ liệu trong hệ sinh thái.

Relational Databases

Cơ sở dữ liệu quan hệ (còn được gọi là RDBMS) đã là lựa chọn cơ sở dữ liệu trong hơn ba thập kỷ. Có giá trị đáng kể trong việc sử dụng chúng và sự ổn định mà chúng cung cấp, đặc biệt là trong hầu hết các ứng dụng liên quan đến kinh doanh. Các cơ sở dữ liệu này nổi tiếng với Ngôn ngữ Truy vấn Có cấu trúc (SQL) phổ biến và các thuộc tính ACID mà chúng cung cấp. Giao diện SQL mà chúng cung cấp làm cho chúng trở thành lựa chọn ưu tiên để triển khai các mô hình đọc khác nhau dựa trên cùng một mô hình ghi. Xếp hạng sao cho các cơ sở dữ liệu quan hệ xuất hiện trong Hình 6-25.

Figure 6-25. Relational databases rated for various adoption characteristics

Ease-of-learning curve

Cơ sở dữ liệu quan hệ đã tồn tại nhiều năm. Chúng thường được dạy trong các trường học, và có nhiều tài liệu cũng như hướng dẫn trưởng thành. Do đó, chúng dễ học hơn nhiều so với các loại cơ sở dữ liệu khác.

Ease of data modeling

Cơ sở dữ liệu quan hệ cho phép mô hình hóa dữ liệu linh hoạt. Chúng cho phép mô hình hóa các cấu trúc khóa-giá trị, tài liệu, giống như đồ thị, và cho phép thay đổi trong các mẫu đọc bằng cách thêm các chỉ mục mới. Một số mô hình thực sự khó đạt được, chẳng hạn như các cấu trúc đồ thị có độ sâu tùy ý. Cơ sở dữ liệu quan hệ tổ chức dữ liệu thành các bảng và hàng (tương tự như bảng tính), điều này là tự nhiên đối với hầu hết các nhà lập mô hình cơ sở dữ liệu.

Scalability/throughput

Cơ sở dữ liệu quan hệ thường được mở rộng theo chiều dọc bằng cách sử dụng các máy lớn. Tuy nhiên, việc thiết lập với các bản sao và chuyển đổi tự động khá phức tạp, yêu cầu sự phối hợp và thiết lập cao hơn.

Availability/partition tolerance

Cơ sở dữ liệu quan hệ ưu tiên tính nhất quán hơn khả năng sẵn có và khả năng chịu phân đoạn, được thảo luận trong “Kỹ thuật chia bảng”.

Consistency

Cơ sở dữ liệu quan hệ đã thống trị trong nhiều năm bởi vì sự hỗ trợ cho các thuộc tính ACID. Các tính năng ACID xử lý nhiều vấn đề trong các hệ thống đồng thời và cho phép phát triển ứng dụng mà không cần lo lắng về các chi tiết cấp thấp của tính đồng thời và cách mà các cơ sở dữ liệu xử lý chúng.

Programming language support, product maturity, SQL support, and community

Vì cơ sở dữ liệu quan hệ đã tồn tại trong nhiều năm, các mẫu thiết kế, thực hiện và vận hành đã được biết đến có thể được áp dụng cho chúng, do đó, chúng trở nên dễ dàng để áp dụng, phát triển và tích hợp trong một kiến trúc. Nhiều cơ sở dữ liệu quan hệ thiếu hỗ trợ cho các API luồng phản ứng và các khái niệm mới tương tự; các khái niệm kiến trúc mới hơn mất nhiều thời gian hơn để triển khai trong các cơ sở dữ liệu quan hệ đã được thiết lập vững chắc. Nhiều giao diện ngôn ngữ lập trình hoạt động với cơ sở dữ liệu quan hệ, và cộng đồng người dùng thì lớn (mặc dù bị phân tán giữa tất cả các nhà cung cấp).

Read/write priority

Trong các cơ sở dữ liệu quan hệ, mô hình dữ liệu có thể được thiết kế theo cách mà hoặc là đọc trở nên hiệu quả hơn, hoặc là ghi trở nên hiệu quả hơn. Cùng một cơ sở dữ liệu có thể xử lý nhiều loại khối lượng công việc khác nhau, cho phép ưu tiên đọc-ghi được cân bằng. Ví dụ, không phải tất cả các trường hợp sử dụng đều cần các thuộc tính ACID, đặc biệt là trong các kịch bản dữ liệu lớn và lưu lượng truy cập cao, hoặc khi mong muốn có một cấu trúc linh hoạt thực sự, chẳng hạn như trong quản trị khảo sát. Trong những trường hợp này, các loại cơ sở dữ liệu khác có thể là một lựa chọn tốt hơn.

MySQL, Oracle, Microsoft SQL Server và PostgreSQL là những cơ sở dữ liệu quan hệ phổ biến nhất và có thể được cài đặt độc lập hoặc có sẵn dưới dạng Dịch vụ Cơ sở dữ liệu trên các nền tảng cung cấp điện toán đám mây lớn.

Key-Value Databases

Cơ sở dữ liệu khóa-giá trị tương tự như cấu trúc dữ liệu bảng băm, giống như các bảng trong RDBMS với một cột ID làm khóa và một cột blob làm giá trị, do đó có thể lưu trữ bất kỳ loại dữ liệu nào. Cơ sở dữ liệu khóa-giá trị là một phần của một gia đình được gọi là cơ sở dữ liệu NoSQL. Trong cuốn sách NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence (Addison-Wesley), Pramod Sadalage (một trong những tác giả) và Martin Fowler mô tả sự phát triển của các cơ sở dữ liệu NoSQL và các động lực, cách sử dụng, và các thỏa hiệp khi sử dụng loại cơ sở dữ liệu này, và là một tài liệu tham khảo tốt để tìm hiểu thêm về loại cơ sở dữ liệu này.

Cơ sở dữ liệu key-value dễ hiểu nhất trong số các cơ sở dữ liệu NoSQL. Một ứng dụng client có thể chèn một khóa và một giá trị, lấy giá trị cho một khóa đã biết, hoặc xóa một khóa đã biết cùng với giá trị của nó. Cơ sở dữ liệu key-value không biết nội dung bên trong phần giá trị, cũng như không quan tâm đến nội dung bên trong, có nghĩa là cơ sở dữ liệu chỉ có thể truy vấn bằng khóa và không gì khác.

Không giống như cơ sở dữ liệu quan hệ, cơ sở dữ liệu key-value nên được lựa chọn dựa trên nhu cầu. Có những cơ sở dữ liệu key-value bền vững như Amazon DynamoDB hoặc Riak KV, cơ sở dữ liệu không bền vững như MemcacheDB, và các cơ sở dữ liệu khác như Redis có thể được cấu hình để bền vững hoặc không. Các cấu trúc cơ sở dữ liệu quan hệ khác như joins, where, và order by không được hỗ trợ, mà thay vào đó là các thao tác get, put và delete. Xếp hạng cho các cơ sở dữ liệu key-value xuất hiện trong Hình 6-26.

Figure 6-26. Key-value databases rated for various adoption characteristics

Ease-of-learning curve

Cơ sở dữ liệu key-value rất dễ hiểu. Vì chúng sử dụng "Hướng tổng hợp", nên việc thiết kế tổng hợp là rất quan trọng vì bất kỳ thay đổi nào trong tổng hợp đều có nghĩa là phải ghi lại tất cả dữ liệu. Việc chuyển từ cơ sở dữ liệu quan hệ sang bất kỳ cơ sở dữ liệu NoSQL nào cần phải tập luyện và quên đi những thói quen quen thuộc. Ví dụ, một nhà phát triển không thể đơn giản truy vấn "Lấy cho tôi tất cả các khóa."

Ease of data modeling

Vì các cơ sở dữ liệu key-value được định hướng theo tổng hợp, chúng có thể sử dụng các cấu trúc bộ nhớ như mảng, bản đồ, hoặc bất kỳ loại dữ liệu nào khác, bao gồm cả blob lớn. Dữ liệu chỉ có thể được truy vấn bằng khóa hoặc ID, có nghĩa là khách hàng cần phải có quyền truy cập vào khóa bên ngoài cơ sở dữ liệu. Một số ví dụ tốt về khóa bao gồm session_id, user_id và order_id.

Scalability/throughput

Vì các cơ sở dữ liệu key-value được lập chỉ mục theo khóa hoặc ID, việc tra cứu khóa rất nhanh chóng vì không có các phép nối hoặc sắp xếp. Giá trị được lấy và trả về cho khách hàng, điều này cho phép dễ dàng mở rộng và tăng khả năng thông lượng.

Availability/partition tolerance

Vì có nhiều loại cơ sở dữ liệu key-value và mỗi loại có những đặc tính khác nhau, ngay cả cùng một cơ sở dữ liệu cũng có thể được cấu hình để hoạt động theo nhiều cách khác nhau, cả cho một cài đặt lẫn cho mỗi lần đọc. Ví dụ, trong Riak, người dùng có thể sử dụng các thuộc tính quorum như all, one, quorum và default. Khi chúng ta sử dụng quorum là one, truy vấn có thể trả về thành công khi bất kỳ một nút nào phản hồi. Khi sử dụng quorum là all, tất cả các nút phải phản hồi để truy vấn trả về thành công. Mỗi truy vấn có thể điều chỉnh độ khoan dung của phân vùng và khả năng sẵn có. Do đó, giả định rằng tất cả các kho lưu trữ key-value đều giống nhau là một sai lầm.

Consistency

Trong mỗi thao tác ghi, chúng ta có thể áp dụng các cấu hình tương tự như khi áp dụng quorum trong các thao tác đọc; các cấu hình này cung cấp cái được gọi là độ nhất quán có thể điều chỉnh. Độ nhất quán cao hơn có thể đạt được bằng cách đánh đổi độ trễ. Để một thao tác ghi được coi là rất nhất quán, tất cả các nút phải phản hồi, điều này làm giảm khả năng chịu partition. Sử dụng quorum đa số được coi là một sự đánh đổi hợp lý.

Programming language support, product maturity, SQL support, and community

Cơ sở dữ liệu khóa-giá trị có hỗ trợ tốt cho ngôn ngữ lập trình, và nhiều cơ sở dữ liệu mã nguồn mở có cộng đồng tích cực để giúp học hỏi và hiểu chúng. Vì hầu hết các cơ sở dữ liệu đều có API REST HTTP, nên chúng dễ dàng hơn rất nhiều để liên kết.

Read/write priority

Vì các cơ sở dữ liệu kiểu key-value tập trung vào việc tổng hợp, việc truy cập dữ liệu thông qua khóa hoặc ID hướng đến ưu tiên đọc. Cơ sở dữ liệu key-value có thể được sử dụng cho lưu trữ phiên và cũng có thể được sử dụng để lưu cache các thuộc tính và sở thích của người dùng.

Document Databases

Tài liệu như JSON hoặc XML là cơ sở của cơ sở dữ liệu tài liệu. Tài liệu có thể đọc được bởi con người, tự mô tả và là cấu trúc cây phân cấp. Cơ sở dữ liệu tài liệu là một loại cơ sở dữ liệu NoSQL khác, mà xếp hạng của nó xuất hiện trong Hình 6-27. Những cơ sở dữ liệu này hiểu cấu trúc của dữ liệu và có thể lập chỉ mục nhiều thuộc tính của các tài liệu, cho phép linh hoạt hơn trong việc truy vấn.

Figure 6-27. Document databases rated for various adoption characteristics

Ease-of-learning curve

Cơ sở dữ liệu tài liệu giống như cơ sở dữ liệu key-value, trong đó giá trị có thể đọc được bằng con người. Điều này giúp việc học cách sử dụng cơ sở dữ liệu trở nên dễ dàng hơn. Các doanh nghiệp quen làm việc với tài liệu, chẳng hạn như XML và JSON trong các ngữ cảnh khác nhau, chẳng hạn như payload API và giao diện front-end JavaScript.

Ease of data modeling

Cũng giống như các cơ sở dữ liệu kiểu key-value, mô hình hóa dữ liệu liên quan đến việc mô hình hóa các tập hợp như đơn hàng, vé và các đối tượng miền khác. Các cơ sở dữ liệu tài liệu khá linh hoạt khi nói đến thiết kế tập hợp, vì các phần của tập hợp có thể được truy vấn và có thể được lập chỉ mục.

Scalability/throughput

Cơ sở dữ liệu tài liệu tập trung vào tập hợp và dễ dàng mở rộng. Chỉ số phức tạp làm giảm khả năng mở rộng, và kích thước dữ liệu tăng lên dẫn đến nhu cầu phân vùng hoặc chia nhỏ. Khi phân chia nhỏ được giới thiệu, nó làm tăng độ phức tạp và cũng buộc phải chọn một khóa phân chia.

Availability/partition tolerance

Giống như các cơ sở dữ liệu kiểu key-value, cơ sở dữ liệu tài liệu có thể được cấu hình cho khả năng sẵn có cao hơn. Việc thiết lập trở nên phức tạp khi có các cụm sao chép cho các bộ sưu tập phân mảnh. Các nhà cung cấp dịch vụ đám mây đang cố gắng làm cho những thiết lập này dễ sử dụng hơn.

Consistency

Một số cơ sở dữ liệu tài liệu đã bắt đầu hỗ trợ giao dịch ACID trong một bộ sưu tập, nhưng điều này có thể không hoạt động trong một số trường hợp biên. Giống như các cơ sở dữ liệu khóa-giá trị, các cơ sở dữ liệu tài liệu cung cấp khả năng tinh chỉnh các hoạt động đọc và ghi bằng cách sử dụng cơ chế số phiếu bầu.

Programming language support, product maturity, SQL support, and community

Cơ sở dữ liệu tài liệu là loại cơ sở dữ liệu NoSQL phổ biến nhất, với một cộng đồng người dùng năng động, nhiều hướng dẫn học trực tuyến và nhiều trình điều khiển ngôn ngữ lập trình cho phép dễ dàng áp dụng hơn.

Read/write priority

Cơ sở dữ liệu tài liệu thiên về tập hợp và có các chỉ mục thứ cấp để truy vấn, vì vậy các cơ sở dữ liệu này ưu tiên cho việc đọc.

Column Family Databases

Cơ sở dữ liệu dạng cột, còn được gọi là cơ sở dữ liệu cột rộng hoặc cơ sở dữ liệu bảng lớn, có các hàng với số lượng cột khác nhau, trong đó mỗi cột là một cặp tên-giá trị. Với các cơ sở dữ liệu dạng cột, tên được gọi là khóa cột, giá trị được gọi là giá trị cột, và khóa chính của một hàng được gọi là khóa hàng. Cơ sở dữ liệu dạng cột là một loại cơ sở dữ liệu NoSQL khác nhóm dữ liệu liên quan có thể được truy cập cùng một lúc, và các đánh giá của chúng xuất hiện trong Hình 6-28.

Figure 6-28. Column family databases rated for various adoption characteristics

Ease-of-learning curve

Cơ sở dữ liệu dạng cột là khó hiểu. Vì một tập hợp các cặp tên-giá trị thuộc về một hàng, nên mỗi hàng có thể có các cặp tên-giá trị khác nhau. Một số cặp tên-giá trị có thể có một bản đồ các cột và được gọi là siêu cột. Hiểu cách sử dụng chúng cần có thời gian và thực hành.

Ease of data modeling

Mô hình dữ liệu với cơ sở dữ liệu dạng cột cần thời gian để làm quen. Dữ liệu cần được sắp xếp thành các nhóm cặp tên-giá trị có một định danh hàng duy nhất, và thiết kế khóa hàng này cần nhiều vòng lặp. Một số cơ sở dữ liệu dạng cột như Apache Cassandra đã giới thiệu một ngôn ngữ truy vấn giống SQL được gọi là Cassandra Query Language (CQL), giúp cho việc mô hình hóa dữ liệu trở nên dễ tiếp cận hơn.

Scalability/throughput

Tất cả các cơ sở dữ liệu dạng gia đình cột đều có khả năng mở rộng cao và phù hợp với các trường hợp sử dụng cần thông lượng ghi hoặc đọc cao. Các cơ sở dữ liệu dạng gia đình cột có thể mở rộng ngang cho các hoạt động đọc và ghi.

Availability/partition tolerance

Cơ sở dữ liệu dạng cột tự nhiên hoạt động trong các cụm, và khi một số nút của cụm gặp sự cố, điều này là xuyên suốt với khách hàng. Hệ số sao chép mặc định là ba, có nghĩa là ít nhất ba bản sao dữ liệu được tạo ra, nâng cao khả năng sẵn sàng và khả năng chịu phân vùng. Tương tự như cơ sở dữ liệu key-value và tài liệu, cơ sở dữ liệu dạng cột có thể điều chỉnh việc ghi và đọc dựa trên nhu cầu đa số.

Consistency

Cơ sở dữ liệu dạng cột, giống như các cơ sở dữ liệu NoSQL khác, tuân theo khái niệm tính nhất quán có thể điều chỉnh. Điều này có nghĩa là, tùy thuộc vào nhu cầu, mỗi thao tác có thể quyết định mức độ nhất quán mong muốn. Ví dụ, trong các kịch bản ghi cao, nơi một số mất mát dữ liệu có thể được chấp nhận, mức độ nhất quán ghi là ANY có thể được sử dụng, có nghĩa là ít nhất một nút đã chấp nhận ghi, trong khi mức độ nhất quán ALL có nghĩa là tất cả các nút phải chấp nhận ghi và phản hồi thành công. Các mức độ nhất quán tương tự có thể áp dụng cho các thao tác đọc. Đây là một sự đánh đổi—các mức độ nhất quán cao hơn làm giảm khả năng sẵn có và khả năng phân đoạn.

Programming language support, product maturity, SQL support, and community

Cơ sở dữ liệu kiểu cột như Cassandra và Scylla có cộng đồng hoạt động năng nổ, và việc phát triển các giao diện tương tự SQL đã giúp việc áp dụng những cơ sở dữ liệu này dễ dàng hơn.

Read/write priority

Cơ sở dữ liệu dạng gia đình cột sử dụng các khái niệm về SSTables, nhật ký cam kết (commit logs) và memtables, và vì các cặp tên-giá trị được lấp đầy khi có dữ liệu, chúng có thể xử lý dữ liệu thưa thớt tốt hơn nhiều so với cơ sở dữ liệu quan hệ. Chúng lý tưởng cho các kịch bản có khối lượng ghi cao.

Tất cả các cơ sở dữ liệu NoSQL đều được thiết kế để hiểu được định hướng tổng hợp. Việc có các tập hợp dữ liệu (aggregates) cải thiện hiệu suất đọc và ghi, và cũng cho phép có khả năng sẵn sàng cao hơn và độ tolérance phân tán khi các cơ sở dữ liệu được chạy trong dạng cụm. Khái niệm định lý CAP được đề cập chi tiết hơn trong "Kỹ thuật phân tách bảng".

Graph Databases

Khác với cơ sở dữ liệu quan hệ, nơi mà các quan hệ được ngầm hiểu dựa trên các tham chiếu, cơ sở dữ liệu đồ thị sử dụng các nút để lưu trữ các thực thể và thuộc tính của chúng. Các nút này được kết nối bằng các cạnh, còn được gọi là quan hệ, là những đối tượng rõ ràng. Các nút được tổ chức theo các quan hệ và cho phép phân tích dữ liệu kết nối bằng cách duyệt theo các cạnh cụ thể.

Figure 6-29. In graph databases, direction of the edge has significance when querying

Các cạnh trong cơ sở dữ liệu đồ thị có ý nghĩa hướng. Trong Hình 6-29, một cạnh loại TICKET_CREATED kết nối một nút vé với ID 4235143 đến một nút khách hàng với ID Neal. Chúng ta có thể đi qua từ nút vé qua cạnh hướng ra TICKET_CREATED hoặc từ nút khách hàng qua cạnh hướng vào TICKET_CREATED. Khi các hướng bị lẫn lộn, việc truy vấn đồ thị trở nên rất khó khăn. Các đánh giá cho cơ sở dữ liệu đồ thị được minh họa trong Hình 6-29.

Figure 6-30. Graph databases rated for various adoption characteristics

Ease-of-learning curve

Cơ sở dữ liệu đồ thị có một đường cong học tập dốc. Việc hiểu cách sử dụng các nút, mối quan hệ, loại mối quan hệ và thuộc tính mất thời gian.

Ease of data modeling

Hiểu cách mô hình hóa các miền và chuyển đổi chúng thành các nút và quan hệ là rất khó. Ban đầu, xu hướng là thêm thuộc tính vào các quan hệ. Khi kiến thức mô hình cải thiện, việc sử dụng ngày càng nhiều các nút và quan hệ, và chuyển đổi một số thuộc tính quan hệ thành nút với loại quan hệ bổ sung diễn ra, điều này cải thiện việc duyệt đồ thị.

Scalability/throughput

Các nút sao chép cải thiện khả năng mở rộng đọc, và thông lượng có thể được điều chỉnh cho các tải đọc. Vì việc chia tách hoặc phân đoạn đồ thị là khó khăn, thông lượng ghi bị hạn chế bởi loại cơ sở dữ liệu đồ thị được chọn. Việc duyệt các mối quan hệ rất nhanh chóng, vì việc lập chỉ mục và lưu trữ được duy trì và không được tính toán tại thời gian truy vấn.

Availability/partition tolerance

Một số cơ sở dữ liệu đồ thị có khả năng phân vùng cao và tính khả dụng cao là phân tán. Các cụm cơ sở dữ liệu đồ thị có thể sử dụng các nút có thể được thăng chức thành lãnh đạo khi các lãnh đạo hiện tại không có sẵn.

Consistency

Nhiều cơ sở dữ liệu đồ thị hỗ trợ giao dịch ACID. Một số cơ sở dữ liệu đồ thị, chẳng hạn như Neo4j, hỗ trợ giao dịch, để dữ liệu luôn nhất quán.

Programming language support, product maturity, SQL support, and community

Cơ sở dữ liệu đồ thị có nhiều hỗ trợ từ cộng đồng. Nhiều thuật toán, như thuật toán Dijkstra hoặc độ tương đồng của nút, được triển khai trong cơ sở dữ liệu, giảm nhu cầu viết chúng từ đầu. Khung ngôn ngữ được gọi là Gremlin hoạt động trên nhiều cơ sở dữ liệu khác nhau, giúp dễ sử dụng hơn. Neo4J hỗ trợ một ngôn ngữ truy vấn được gọi là Cypher, cho phép các nhà phát triển dễ dàng truy vấn cơ sở dữ liệu.

Read/write priority

Trong cơ sở dữ liệu đồ thị, việc lưu trữ dữ liệu được tối ưu hóa cho việc duyệt các mối quan hệ, trái ngược với các cơ sở dữ liệu quan hệ, nơi chúng ta phải truy vấn các mối quan hệ và suy luận chúng tại thời điểm truy vấn. Cơ sở dữ liệu đồ thị tốt hơn cho các kịch bản yêu cầu đọc dữ liệu nhiều.

Cơ sở dữ liệu đồ thị cho phép cùng một nút có nhiều loại mối quan hệ khác nhau. Trong ví dụ của Đội Sysops, một đồ thị mẫu có thể trông như sau: một knowledge_base được tạo ra bởi người dùng sysops_user và knowledge_base được sử dụng bởi sysops_user. Do đó, các mối quan hệ created_by và used_by kết nối các nút giống nhau cho các loại mối quan hệ khác nhau.

NewSQL Databases

Matthew Aslett lần đầu tiên sử dụng thuật ngữ NewSQL để định nghĩa các cơ sở dữ liệu mới nhằm cung cấp khả năng mở rộng của các cơ sở dữ liệu NoSQL đồng thời hỗ trợ các tính năng của cơ sở dữ liệu quan hệ như ACID. Các cơ sở dữ liệu NewSQL sử dụng các loại cơ chế lưu trữ khác nhau, và tất cả chúng đều hỗ trợ SQL.

Cơ sở dữ liệu NewSQL, có xếp hạng xuất hiện trong Hình 6-31, cải thiện các cơ sở dữ liệu quan hệ bằng cách cung cấp phân vùng dữ liệu tự động hoặc sharding, cho phép mở rộng theo chiều ngang và tăng cường khả năng sẵn sàng, trong khi vẫn cho phép các nhà phát triển dễ dàng chuyển đổi sang việc sử dụng mô hình quen thuộc của SQL và ACID.

Figure 6-31. New SQL databases rated for various adoption characteristics

Ease-of-learning curve

Vì các cơ sở dữ liệu NewSQL giống như các cơ sở dữ liệu quan hệ (với giao diện SQL, có thêm tính năng mở rộng theo chiều ngang, tuân thủ ACID), nên việc học sẽ dễ dàng hơn. Một số trong số đó chỉ có sẵn dưới dạng Dịch vụ Cơ sở dữ liệu (DBaaS), điều này có thể khiến việc học trở nên khó khăn hơn.

Ease of data modeling

Vì các cơ sở dữ liệu NewSQL tương tự như cơ sở dữ liệu quan hệ, việc mô hình hóa dữ liệu là quen thuộc đối với nhiều người và dễ tiếp thu hơn. Đặc điểm thêm là thiết kế phân mảnh, cho phép đặt dữ liệu phân mảnh tại các vị trí địa lý khác nhau.

Scalability/throughput

Cơ sở dữ liệu NewSQL được thiết kế để hỗ trợ mở rộng theo chiều ngang cho các hệ thống phân tán, cho phép có nhiều nút hoạt động, khác với cơ sở dữ liệu quan hệ chỉ có một lãnh đạo hoạt động và các nút còn lại là các nút theo sau. Nhiều nút hoạt động cho phép cơ sở dữ liệu NewSQL có khả năng mở rộng cao và đạt được hiệu suất tốt hơn.

Availability/partition tolerance

Nhờ vào thiết kế nhiều nút hoạt động, lợi ích về tính sẵn sàng có thể rất cao với khả năng chịu phân vùng tốt hơn. CockroachDB là một cơ sở dữ liệu NewSQL phổ biến có khả năng sống sót qua các sự cố về đĩa, máy móc và trung tâm dữ liệu.

Consistency

Cơ sở dữ liệu NewSQL hỗ trợ các giao dịch ACID đồng nhất mạnh mẽ. Dữ liệu luôn nhất quán, điều này cho phép người dùng cơ sở dữ liệu quan hệ dễ dàng chuyển sang cơ sở dữ liệu NewSQL.

Programming language support, product maturity, SQL support, and community

Có nhiều cơ sở dữ liệu NewSQL mã nguồn mở, vì vậy việc học chúng là dễ dàng. Một số cơ sở dữ liệu cũng hỗ trợ các giao thức tương thích với các cơ sở dữ liệu quan hệ hiện có, cho phép chúng thay thế các cơ sở dữ liệu quan hệ mà không gặp phải vấn đề tương thích nào.

Read/write priority

Cơ sở dữ liệu NewSQL được sử dụng giống như cơ sở dữ liệu quan hệ, với những lợi ích bổ sung về lập chỉ mục và phân phối địa lý, nhằm cải thiện hiệu suất đọc hoặc hiệu suất ghi.

Cloud Native Databases

Với việc tăng cường sử dụng đám mây, các cơ sở dữ liệu đám mây như Snowflake, Amazon Redshift, Datomic và Azure CosmosDB đã trở nên phổ biến hơn. Những cơ sở dữ liệu này giảm bớt gánh nặng vận hành, cung cấp sự minh bạch về chi phí và là một cách dễ dàng để thử nghiệm vì không cần đầu tư ban đầu. Các đánh giá về cơ sở dữ liệu gốc đám mây xuất hiện trong Hình 6-32.

Figure 6-32. Cloud native databases rated for various adoption characteristics

Ease-of-learning curve

Một số cơ sở dữ liệu đám mây như AWS Redshift giống như các cơ sở dữ liệu quan hệ và do đó dễ hiểu hơn. Các cơ sở dữ liệu như Snowflake, có giao diện SQL nhưng có cơ chế lưu trữ và tính toán khác nhau, cần một chút thời gian luyện tập. Datomic hoàn toàn khác biệt về mặt mô hình và sử dụng các sự thật nguyên tử không thay đổi. Do đó, độ dốc của việc học tập thay đổi tùy thuộc vào từng sản phẩm cơ sở dữ liệu.

Ease of data modeling

Datomic không có khái niệm về bảng hoặc cần xác định thuộc tính trước. Cần định nghĩa các thuộc tính của từng thuộc tính cá nhân, và các thực thể có thể có bất kỳ thuộc tính nào. Snowflake và Redshift thường được sử dụng cho các khối lượng công việc kiểu kho dữ liệu. Hiểu loại mô hình mà cơ sở dữ liệu cung cấp là rất quan trọng trong việc lựa chọn cơ sở dữ liệu để sử dụng.

Scalability/throughput

Vì tất cả các cơ sở dữ liệu này chỉ có trên đám mây, việc mở rộng chúng tương đối đơn giản vì các tài nguyên có thể được phân bổ tự động với một mức giá. Trong những quyết định này, sự đánh đổi thường liên quan đến giá cả.

Availability/partition tolerance

Các cơ sở dữ liệu trong danh mục này (như Datomic) có khả năng sẵn sàng cao khi được triển khai theo Topology Sản xuất. Chúng không có điểm lỗi đơn lẻ và được hỗ trợ bởi bộ đệm mở rộng. Snowflake, chẳng hạn, sao chép các cơ sở dữ liệu của mình qua các khu vực và tài khoản. Các cơ sở dữ liệu khác trong danh mục này hỗ trợ khả năng sẵn sàng cao hơn với nhiều tùy chọn cấu hình khác nhau. Ví dụ, Redshift hoạt động trong một khu vực khả dụng duy nhất và cần được chạy trên nhiều cụm để hỗ trợ khả năng sẵn sàng cao hơn.

Consistency

Datomic hỗ trợ giao dịch ACID bằng cách sử dụng các động cơ lưu trữ để lưu trữ các khối trong lưu trữ khối. Các cơ sở dữ liệu khác, như Snowflake và Redshift, cũng hỗ trợ giao dịch ACID.

Programming language support, product maturity, SQL support, and community

Nhiều cơ sở dữ liệu trong số này còn mới, và việc tìm kiếm sự trợ giúp có kinh nghiệm có thể khó khăn. Thực nghiệm với các cơ sở dữ liệu này yêu cầu một tài khoản đám mây, điều này có thể tạo ra một rào cản khác. Trong khi các cơ sở dữ liệu gốc đám mây giảm bớt khối lượng công việc vận hành cho các DBA vận hành, chúng có một đường cong học tập cao hơn đối với các nhà phát triển. Datomic sử dụng Clojure trong tất cả các ví dụ của nó, và các thủ tục lưu trữ được viết bằng Clojure, vì vậy không biết Clojure có thể là một rào cản để sử dụng.

Read/write priority

Các cơ sở dữ liệu này có thể được sử dụng cho cả tải nặng về đọc hoặc tải nặng về ghi. Snowflake và Redshift chủ yếu hướng đến các khối lượng công việc kiểu kho dữ liệu, do đó ưu tiên đọc, trong khi Datomic có thể hỗ trợ cả hai loại tải với các chỉ mục khác nhau như EAVT (Thực thể, Thuộc tính, Giá trị, sau đó là Giao dịch) trước.

Time-Series Databases

Dựa trên các xu hướng hiện tại, chúng tôi thấy sự gia tăng trong việc sử dụng IoT, microservices, xe tự lái và khả năng quan sát, tất cả đều đã thúc đẩy một sự gia tăng phi thường trong phân tích chuỗi thời gian. Xu hướng này đã dẫn đến sự ra đời của các cơ sở dữ liệu được tối ưu hóa để lưu trữ các chuỗi điểm dữ liệu được thu thập trong một khoảng thời gian, cho phép người dùng theo dõi các thay đổi trong bất kỳ khoảng thời gian nào. Các xếp hạng cho loại cơ sở dữ liệu này xuất hiện trong Hình 6-33.

Figure 6-33. Time-series databases rated for various adoption characteristics

Ease-of-learning curve

Hiểu dữ liệu theo chuỗi thời gian thường dễ dàng—mỗi điểm dữ liệu gắn liền với một mốc thời gian, và dữ liệu gần như luôn được chèn vào và không bao giờ được cập nhật hoặc xóa. Hiểu các thao tác chỉ thêm đòi hỏi một số sự từ bỏ những gì đã học từ việc sử dụng cơ sở dữ liệu khác, nơi mà các lỗi trong dữ liệu có thể được sửa chữa bằng một lần cập nhật. InfluxDB, Kx, và TimeScale là một số cơ sở dữ liệu theo chuỗi thời gian phổ biến.

Ease of data modeling

Khái niệm cơ bản của cơ sở dữ liệu chuỗi thời gian là phân tích sự thay đổi của dữ liệu theo thời gian. Ví dụ, với ví dụ về Đội Sysops, những thay đổi được thực hiện đối với một đối tượng vé có thể được lưu trữ trong cơ sở dữ liệu chuỗi thời gian, nơi mà thời gian thay đổi và ticket_id được đánh dấu. Việc thêm nhiều thông tin vào một thẻ được coi là thực hành không tốt. Ví dụ, ticket_status=Open, ticket_id=374737 thì tốt hơn là ticket_info=Open.374737.

Scalability/throughput

Timescale được xây dựng dựa trên PostgreSQL và cho phép mở rộng chuẩn và cải thiện thông lượng. Chạy InfluxDB ở chế độ cluster bằng cách sử dụng các nút meta để quản lý siêu dữ liệu và các nút dữ liệu để lưu trữ dữ liệu thực tế mang lại sự cải thiện về khả năng mở rộng và thông lượng.

Availability/partition tolerance

Một số cơ sở dữ liệu như InfluxDB có sự lựa chọn về khả năng sẵn có và độ chịu phân vùng tốt hơn với cấu hình cho các nút meta và dữ liệu, cùng với các yếu tố sao chép.

Consistency

Cơ sở dữ liệu chuỗi thời gian sử dụng cơ sở dữ liệu quan hệ làm động cơ lưu trữ của chúng đạt được các thuộc tính ACID để đảm bảo tính nhất quán, trong khi các cơ sở dữ liệu khác có thể điều chỉnh tính nhất quán bằng cách sử dụng mức độ nhất quán là bất kỳ, một hoặc đa số. Cấu hình mức độ nhất quán cao hơn thường dẫn đến tính nhất quán cao hơn và khả năng sẵn có thấp hơn, vì vậy đây là một sự đánh đổi cần được cân nhắc.

Programming language support, product maturity, SQL support, and community

Cơ sở dữ liệu chuỗi thời gian đã trở nên phổ biến gần đây, và có nhiều tài nguyên để học hỏi. Một số cơ sở dữ liệu này, chẳng hạn như InfluxDB, cung cấp một ngôn ngữ truy vấn giống SQL được gọi là InfluxQL.

Read/write priority

Cơ sở dữ liệu theo chuỗi thời gian chỉ cho phép thêm dữ liệu và thường phù hợp hơn cho các khối lượng công việc chủ yếu đọc.

Khi sử dụng cơ sở dữ liệu thời gian, cơ sở dữ liệu tự động gán một dấu thời gian vào mỗi dữ liệu được tạo, và dữ liệu chứa các thẻ hoặc thuộc tính thông tin. Dữ liệu được truy vấn dựa trên một số yếu tố giữa các khoảng thời gian cụ thể. Do đó, cơ sở dữ liệu thời gian không phải là cơ sở dữ liệu đa năng.

Tóm tắt tất cả các loại cơ sở dữ liệu đã được thảo luận trong phần này, Bảng 6-6 cho thấy một số sản phẩm cơ sở dữ liệu phổ biến cho loại cơ sở dữ liệu đó.

Service Scope and Function

Phạm vi và chức năng dịch vụ là yếu tố đầu tiên và phổ biến nhất để chia nhỏ một dịch vụ đơn thành các dịch vụ nhỏ hơn, đặc biệt là liên quan đến microservices. Có hai khía cạnh cần xem xét khi phân tích phạm vi và chức năng dịch vụ. Khía cạnh đầu tiên là độ gắn kết: mức độ và cách mà các hoạt động của một dịch vụ cụ thể liên quan đến nhau. Khía cạnh thứ hai là kích thước tổng thể của một thành phần, thường được đo bằng tổng số câu lệnh được cộng lại từ các lớp tạo nên dịch vụ đó, số điểm vào công khai vào dịch vụ, hoặc cả hai.

Xem xét một dịch vụ Thông báo điển hình, dịch vụ này thực hiện ba việc: thông báo cho khách hàng qua SMS (Dịch vụ Tin nhắn Ngắn), email, hoặc một bức thư in gửi qua đường bưu điện đến khách hàng. Mặc dù rất hấp dẫn để chia dịch vụ này thành ba dịch vụ đơn mục đích riêng biệt (một cho SMS, một cho email, và một cho thư bưu chính) như được minh họa trong Hình 7-2, nhưng điều này một mình không đủ để biện minh cho việc tách dịch vụ ra, vì nó đã có sự kết hợp tương đối mạnh - tất cả các chức năng này liên quan đến một điều, đó là thông báo cho khách hàng. Vì “mục đích đơn” để lại cho ý kiến và diễn giải cá nhân, nên rất khó để biết có nên tách dịch vụ này hay không.

Figure 7-2. A service with relatively strong cohesion is not a good candidate for disintegration based on functionality alone

Bây giờ hãy xem xét một dịch vụ đơn lẻ quản lý thông tin hồ sơ khách hàng, sở thích của khách hàng và cả những bình luận của khách hàng được thực hiện trên trang web. Khác với ví dụ Dịch vụ Thông báo trước đó, dịch vụ này có độ kết hợp tương đối yếu vì ba chức năng này liên quan đến một phạm vi rộng hơn - khách hàng. Dịch vụ này có thể đang đảm nhận quá nhiều công việc, và do đó có lẽ nên được chia thành ba dịch vụ riêng biệt, như được minh họa trong Hình 7-3.

Figure 7-3. A service with relatively weak cohesion is a good candidate for disintegration

Thiết bị phân tán độ chi tiết này có liên quan đến nguyên tắc trách nhiệm đơn lẻ được đặt tên bởi Robert C. Martin như một phần của các nguyên tắc SOLID của ông, nguyên tắc này tuyên bố rằng “mỗi lớp nên có trách nhiệm với một phần chức năng duy nhất của chương trình, mà nó nên bao bọc. Tất cả các dịch vụ của mô-đun, lớp hoặc hàm đó nên được định hướng chặt chẽ với trách nhiệm đó.” Trong khi nguyên tắc trách nhiệm đơn lẻ ban đầu được áp dụng trong bối cảnh các lớp, trong những năm gần đây, nó đã mở rộng để bao gồm các thành phần và dịch vụ.

Trong kiến trúc microservices, một microservice được định nghĩa là một đơn vị phần mềm phục vụ một mục đích duy nhất, được triển khai riêng biệt và thực hiện một nhiệm vụ rất tốt. Không có gì ngạc nhiên khi các lập trình viên có xu hướng thu nhỏ các dịch vụ càng nhiều càng tốt mà không xem xét lý do tại sao họ lại làm như vậy! Sự chủ quan liên quan đến việc cái gì là và không phải là trách nhiệm đơn lẻ chính là nơi mà hầu hết các lập trình viên gặp rắc rối liên quan đến độ granularity của dịch vụ. Mặc dù có một số chỉ số (chẳng hạn như LCOM) để đo lường độ kết hợp, nhưng nó vẫn rất chủ quan khi nói đến dịch vụ - việc thông báo cho khách hàng có phải là một nhiệm vụ duy nhất hay thông báo qua email có phải là một nhiệm vụ duy nhất không? Vì lý do này, việc hiểu các yếu tố phân tán độ granularity khác là vô cùng quan trọng để xác định mức độ granularity phù hợp.

Code Volatility

Độ biến động của mã - tỷ lệ thay đổi mã nguồn - là một yếu tố tốt khác để tách một dịch vụ thành các dịch vụ nhỏ hơn. Điều này cũng được gọi là phân tách dựa trên độ biến động. Đo lường khách quan tần suất thay đổi mã trong một dịch vụ (dễ dàng thực hiện thông qua các phương tiện chuẩn trong bất kỳ hệ thống kiểm soát phiên bản mã nguồn nào) đôi khi có thể dẫn đến một lý do tốt để tách biệt một dịch vụ. Hãy xem lại ví dụ về dịch vụ thông báo từ phần trước. Phạm vi dịch vụ (tính gắn kết) một mình không đủ để biện minh cho việc tách biệt dịch vụ. Tuy nhiên, bằng cách áp dụng các chỉ số thay đổi, thông tin liên quan được tiết lộ về dịch vụ.

• Tần suất thay đổi chức năng thông báo SMS: trung bình mỗi sáu tháng

• Tần suất thay đổi chức năng thông báo qua email: mỗi sáu tháng (trung bình)

• Chức năng thông báo thư bưu điện tỷ lệ thay đổi: hàng tuần (trung bình)

Lưu ý rằng tính năng thư bưu chính thay đổi hàng tuần (trung bình), trong khi đó tính năng SMS và email hiếm khi thay đổi. Là một dịch vụ đơn lẻ, bất kỳ thay đổi nào đối với mã thư bưu chính sẽ yêu cầu nhà phát triển phải kiểm tra và triển khai lại toàn bộ dịch vụ, bao gồm cả tính năng SMS và email. Tùy thuộc vào môi trường triển khai, điều này cũng có thể có nghĩa là tính năng SMS và email sẽ không khả dụng khi các thay đổi về thư bưu chính được triển khai. Do đó, với tư cách là một dịch vụ đơn lẻ, phạm vi kiểm tra bị mở rộng và rủi ro triển khai cao. Tuy nhiên, bằng cách chia nhỏ dịch vụ này thành hai dịch vụ riêng biệt (Thông báo điện tử và Thông báo thư bưu chính), như được minh họa trong Hình 7-4, các thay đổi thường xuyên giờ đây được tách biệt vào một dịch vụ nhỏ hơn. Điều này có nghĩa là phạm vi kiểm tra được giảm đáng kể, rủi ro triển khai giảm thấp hơn, và tính năng SMS cùng email không bị gián đoạn trong quá trình triển khai các thay đổi thư bưu chính.

Figure 7-4. An area of high code change in a service is a good candidate for disintegration

Scalability and Throughput

Một lý do khác cho việc chia một dịch vụ thành các dịch vụ nhỏ hơn là khả năng mở rộng và thông lượng. Các yêu cầu về khả năng mở rộng của các chức năng khác nhau của một dịch vụ có thể được đo lường một cách khách quan để xác định xem dịch vụ đó có nên được tách rời hay không. Hãy xem lại ví dụ về Dịch vụ Thông báo, nơi một dịch vụ duy nhất thông báo cho khách hàng qua SMS, email và thư gửi qua đường bưu điện. Đo lường các yêu cầu về khả năng mở rộng của dịch vụ duy nhất này tiết lộ thông tin sau đây:

• Thông báo SMS: 220.000/phút

• Thông báo qua email: 500/phút

• Thông báo thư bưu điện: 1/phút

Lưu ý sự biến đổi cực kỳ giữa việc gửi thông báo SMS và thông báo bằng thư bưu điện. Là một dịch vụ duy nhất, chức năng email và thư bưu điện phải mở rộng không cần thiết để đáp ứng nhu cầu của thông báo SMS, ảnh hưởng đến chi phí và cả tính đàn hồi về thời gian khởi động trung bình (MTTS). Việc chia tách Dịch vụ Thông báo thành ba dịch vụ riêng biệt (SMS, Email và Thư), như được minh họa trong Hình 7-5, cho phép mỗi dịch vụ này có thể mở rộng độc lập để đáp ứng các yêu cầu lưu lượng khác nhau của chúng.

Figure 7-5. Differing scalability and throughput needs is a good disintegration driver

Fault Tolerance

Tính chịu lỗi mô tả khả năng của một ứng dụng hoặc chức năng trong một lĩnh vực cụ thể tiếp tục hoạt động, ngay cả khi xảy ra một sự cố nghiêm trọng (chẳng hạn như tình trạng hết bộ nhớ). Tính chịu lỗi là một động lực tốt khác cho sự phân rã độ chi tiết.

Xem xét ví dụ về Dịch vụ Thông báo hợp nhất tương tự, thông báo cho khách hàng qua SMS, email và thư bưu chính (Hình 7-6). Nếu chức năng email tiếp tục gặp vấn đề với tình trạng hết bộ nhớ và bị sập nghiêm trọng, toàn bộ dịch vụ sẽ ngừng hoạt động, bao gồm cả xử lý SMS và thư bưu chính.

Việc tách dịch vụ Thông báo hợp nhất này thành ba dịch vụ riêng biệt cung cấp một mức độ chịu lỗi cho lĩnh vực thông báo khách hàng. Giờ đây, một lỗi nghiêm trọng trong chức năng của dịch vụ email sẽ không ảnh hưởng đến SMS hoặc thư gửi bưu điện.

Xin lưu ý rằng trong ví dụ này, Dịch vụ Thông báo được chia thành ba dịch vụ riêng biệt (SMS, Email và Thư Bưu chính), mặc dù chức năng email là vấn đề duy nhất liên quan đến các sự cố thường xuyên (hai dịch vụ còn lại rất ổn định). Vì chức năng email là vấn đề duy nhất, tại sao không kết hợp chức năng SMS và thư bưu chính vào một dịch vụ duy nhất?

Xem xét ví dụ về tính không ổn định của mã từ phần trước. Trong trường hợp này, Thư Bưu Chính thay đổi liên tục, trong khi hai dịch vụ còn lại (SMS và Email) thì không. Việc chia nhỏ dịch vụ này thành chỉ hai dịch vụ là hợp lý vì Thư Bưu Chính là chức năng gây ra vấn đề, nhưng Email và SMS có liên quan – cả hai đều liên quan đến việc thông báo cho khách hàng qua điện tử. Bây giờ hãy xem xét ví dụ về khả năng chịu lỗi. SMS thông báo và thông báo Thư Bưu Chính có điểm gì chung ngoài việc thông báo cho khách hàng? Tên gọi tự mô tả phù hợp của dịch vụ kết hợp đó sẽ là gì?

Figure 7-6. Fault tolerance and service availability are good disintegration drivers

Việc chuyển chức năng email sang một dịch vụ riêng biệt làm mất đi sự liên kết tổng thể trong miền, vì sự liên kết giữa chức năng SMS và thư bưu điện trở nên yếu. Hãy cân nhắc những cái tên dịch vụ có thể có: Dịch vụ Email và…Dịch vụ Thông báo Khác? Dịch vụ Email và…Dịch vụ Thông báo SMS-Thư? Dịch vụ Email và…Dịch vụ Không phải Email? Vấn đề đặt tên này liên quan đến phạm vi dịch vụ và mức độ chi tiết của chức năng—nếu một dịch vụ quá khó để đặt tên vì nó làm nhiều việc, hãy cân nhắc phân tách dịch vụ đó. Những sự phân tách dưới đây giúp hình dung điểm quan trọng này:

• Dịch vụ Thông báo → Dịch vụ Email, Dịch vụ Thông báo Khác (tên không hay)

• Dịch vụ Thông báo → Dịch vụ Email, Dịch vụ Không Email (tên không hay)

• Dịch vụ Thông báo → Dịch vụ Email, Dịch vụ SMS-Thư (tên không hay)

• Dịch vụ Thông báo → Dịch vụ Email, Dịch vụ SMS, Dịch vụ Thư (tên hay)

Trong ví dụ này, chỉ có sự phân tách cuối cùng là hợp lý, đặc biệt khi xem xét việc thêm một thông báo từ mạng xã hội khác - điều đó sẽ được đặt ở đâu? Bất cứ khi nào phân tách một dịch vụ, bất kể động lực phân tách là gì, luôn kiểm tra xem liệu có thể tạo ra sự kết hợp mạnh mẽ với các chức năng "còn lại" hay không.

Security

Một cạm bẫy phổ biến khi bảo vệ dữ liệu nhạy cảm là chỉ nghĩ đến việc lưu trữ dữ liệu đó. Ví dụ, việc bảo vệ dữ liệu PCI (Ngành Thẻ Thanh Toán) khỏi dữ liệu không phải PCI có thể được thực hiện thông qua các sơ đồ hoặc cơ sở dữ liệu tách riêng nằm ở các khu vực bảo mật khác nhau. Tuy nhiên, điều thường bị thiếu sót trong thực tiễn này là cũng phải bảo vệ cách thức truy cập vào dữ liệu đó.

Hãy xem xét ví dụ được minh họa trong Hình 7-7 mô tả Dịch vụ Hồ sơ Khách hàng chứa hai chức năng chính: duy trì hồ sơ khách hàng để thêm, thay đổi hoặc xóa thông tin hồ sơ cơ bản (tên, địa chỉ, v.v.); và duy trì thông tin thẻ tín dụng của khách hàng để thêm, xóa và cập nhật thông tin thẻ tín dụng.

Figure 7-7. Security and data access are good disintegration drivers

Mặc dù dữ liệu thẻ tín dụng có thể được bảo vệ, nhưng việc truy cập vào dữ liệu đó đang gặp rủi ro vì chức năng thẻ tín dụng gắn liền với chức năng hồ sơ khách hàng cơ bản. Mặc dù các điểm truy cập API vào dịch vụ hồ sơ khách hàng hợp nhất có thể khác nhau, nhưng vẫn có rủi ro rằng ai đó truy cập vào dịch vụ để lấy tên khách hàng cũng có thể có quyền truy cập vào chức năng thẻ tín dụng. Bằng cách tách dịch vụ này thành hai dịch vụ riêng biệt, quyền truy cập vào chức năng được sử dụng để duy trì thông tin thẻ tín dụng có thể được bảo mật hơn vì tập hợp các hoạt động thẻ tín dụng chỉ đi vào một dịch vụ duy nhất.

Extensibility

Một yếu tố chính khác thúc đẩy sự phân tách độ chi tiết là khả năng mở rộng - khả năng thêm chức năng bổ sung khi ngữ cảnh dịch vụ phát triển. Hãy xem xét một dịch vụ thanh toán quản lý các giao dịch thanh toán và hoàn tiền qua nhiều phương thức thanh toán, bao gồm thẻ tín dụng, thẻ quà tặng và giao dịch PayPal. Giả sử công ty muốn bắt đầu hỗ trợ các phương thức thanh toán khác, như điểm thưởng, tín dụng cửa hàng từ các giao dịch trả lại; và các dịch vụ thanh toán bên thứ ba khác, như ApplePay, SamsungPay, và như vậy. Việc mở rộng dịch vụ thanh toán để thêm các phương thức thanh toán bổ sung này dễ dàng đến mức nào?

Các phương thức thanh toán bổ sung này chắc chắn có thể được thêm vào một dịch vụ thanh toán tập trung duy nhất. Tuy nhiên, mỗi khi một phương thức thanh toán mới được thêm vào, toàn bộ dịch vụ thanh toán sẽ cần phải được kiểm tra (bao gồm cả các loại hình thanh toán khác), và chức năng cho tất cả các phương thức thanh toán khác sẽ bị triển khai lại không cần thiết vào sản xuất. Do đó, với dịch vụ thanh toán tập trung duy nhất, phạm vi kiểm tra được mở rộng và rủi ro triển khai cao hơn, làm cho việc thêm các loại hình thanh toán bổ sung trở nên khó khăn hơn.

Bây giờ hãy xem xét việc tách dịch vụ hợp nhất hiện tại thành ba dịch vụ riêng biệt (Xử lý thẻ tín dụng, Xử lý thẻ quà tặng và Xử lý giao dịch PayPal), như được minh họa trong Hình 7-8.

Bây giờ, khi dịch vụ thanh toán đơn lẻ được chia thành các dịch vụ riêng biệt theo phương thức thanh toán, việc thêm một phương thức thanh toán khác (như điểm thưởng) chỉ là vấn đề phát triển, kiểm tra và triển khai một dịch vụ riêng biệt so với các dịch vụ khác. Kết quả là, quá trình phát triển nhanh hơn, phạm vi kiểm tra được rút gọn và rủi ro khi triển khai thấp hơn.

Lời khuyên của chúng tôi là chỉ áp dụng driver này nếu biết trước rằng các chức năng ngữ cảnh tích hợp bổ sung đang được lên kế hoạch, mong muốn hoặc là một phần của miền bình thường. Ví dụ, với thông báo, có thể nghi ngờ rằng các phương tiện thông báo sẽ không liên tục mở rộng vượt ra ngoài các phương tiện thông báo cơ bản (SMS, email hoặc thư). Tuy nhiên, với xử lý thanh toán, rất có khả năng rằng các loại thanh toán bổ sung sẽ được thêm vào trong tương lai, và do đó cần có các dịch vụ riêng biệt cho mỗi loại thanh toán. Vì thường khó để "đoán" xem liệu (và khi nào) chức năng ngữ cảnh có thể mở rộng (chẳng hạn như các phương thức thanh toán bổ sung), lời khuyên của chúng tôi là chờ đợi driver này như một phương tiện chính để biện minh cho việc phân tách chi tiết cho đến khi một mô hình có thể được thiết lập hoặc xác nhận về khả năng mở rộng liên tục có thể được xác nhận.

Figure 7-8. Planned extensibility is a good disintegration driver

Database Transactions

Hầu hết các hệ thống đơn khối và dịch vụ miền thô sử dụng cơ sở dữ liệu quan hệ dựa vào các giao dịch cơ sở dữ liệu theo đơn vị công việc duy nhất để duy trì tính toàn vẹn và nhất quán của dữ liệu; xem “Giao dịch Phân tán” để biết chi tiết về giao dịch ACID (cơ sở dữ liệu) và cách chúng khác với giao dịch BASE (phân tán). Để hiểu cách các giao dịch cơ sở dữ liệu ảnh hưởng đến độ granularity của dịch vụ, hãy xem xét tình huống được minh họa trong Hình 7-9, nơi chức năng khách hàng đã được chia thành Dịch vụ Hồ sơ Khách hàng duy trì thông tin hồ sơ khách hàng và Dịch vụ Mật khẩu duy trì thông tin và chức năng liên quan đến bảo mật khác.

Lưu ý rằng việc có hai dịch vụ riêng biệt cung cấp một mức độ kiểm soát truy cập bảo mật tốt đối với thông tin mật khẩu vì quyền truy cập ở mức dịch vụ chứ không phải ở mức yêu cầu. Quyền truy cập vào các thao tác như thay đổi mật khẩu, đặt lại mật khẩu và truy cập mật khẩu của khách hàng để đăng nhập có thể được giới hạn trong một dịch vụ duy nhất (và do đó quyền truy cập có thể được giới hạn trong dịch vụ duy nhất đó). Tuy nhiên, trong khi điều này có thể là một động lực tốt để phân tách, hãy xem xét thao tác đăng ký khách hàng mới, như được minh họa trong Hình 7-10.

Figure 7-9. Separate services with atomic operations have better security access control

Figure 7-10. Separate services with combined operations do not support database (ACID) transactions

Khi đăng ký một khách hàng mới, cả thông tin hồ sơ và mật khẩu được mã hóa đều được chuyển vào Dịch vụ Hồ sơ từ một màn hình giao diện người dùng. Dịch vụ Hồ sơ chèn thông tin hồ sơ vào bảng cơ sở dữ liệu tương ứng của nó, thực hiện cam kết công việc đó, và sau đó chuyển thông tin mật khẩu được mã hóa cho Dịch vụ Mật khẩu, dịch vụ này sau đó chèn thông tin mật khẩu vào bảng cơ sở dữ liệu tương ứng của nó và thực hiện cam kết công việc của riêng nó.

Trong khi việc tách biệt các dịch vụ cung cấp kiểm soát truy cập bảo mật tốt hơn cho thông tin mật khẩu, nhược điểm là không có giao dịch ACID cho các hành động như đăng ký một khách hàng mới hoặc hủy đăng ký (xóa) một khách hàng khỏi hệ thống. Nếu dịch vụ mật khẩu gặp sự cố trong bất kỳ thao tác nào trong số này, dữ liệu sẽ bị để lại trong trạng thái không nhất quán, dẫn đến việc xử lý lỗi phức tạp (cũng rất dễ có lỗi) để đảo ngược việc chèn hồ sơ ban đầu hoặc thực hiện các hành động khắc phục khác (xem “Mô hình Giao dịch Saga” để biết chi tiết về tính nhất quán cuối cùng và xử lý lỗi trong các giao dịch phân tán). Do đó, nếu cần có một giao dịch ACID theo đơn vị công việc duy nhất từ góc độ kinh doanh, các dịch vụ này nên được hợp nhất thành một dịch vụ duy nhất, như mô tả trong Hình 7-11.

Figure 7-11. A single service supports database (ACID) transactions

Workflow and Choreography

Một tích hợp độ granularity phổ biến khác là quy trình làm việc và khiêu vũ - các dịch vụ giao tiếp với nhau (đôi khi cũng được gọi là giao tiếp giữa các dịch vụ hoặc giao tiếp theo hướng đông-tây). Giao tiếp giữa các dịch vụ là khá phổ biến và trong nhiều trường hợp là cần thiết trong các kiến trúc phân tán cao như microservices. Tuy nhiên, khi các dịch vụ tiến tới mức độ granularity tinh vi hơn dựa trên các yếu tố phân tán được nêu ở phần trước, giao tiếp giữa các dịch vụ có thể gia tăng đến mức mà các tác động tiêu cực bắt đầu xảy ra.

Vấn đề với khả năng chịu lỗi tổng thể là tác động đầu tiên của việc có quá nhiều giao tiếp đồng bộ giữa các dịch vụ. Hãy xem xét sơ đồ trong Hình 7-12: Dịch vụ A giao tiếp với các dịch vụ B và C, dịch vụ B giao tiếp với dịch vụ C, dịch vụ D giao tiếp với dịch vụ E, và cuối cùng dịch vụ E giao tiếp với dịch vụ C. Trong trường hợp này, nếu dịch vụ C bị sập, tất cả các dịch vụ khác sẽ trở nên không hoạt động do phụ thuộc tranh chấp vào dịch vụ C, tạo ra vấn đề về khả năng chịu lỗi tổng thể, khả năng sẵn sàng và độ tin cậy.

Figure 7-12. Too much workflow impacts fault tolerance

Thú vị là, khả năng chịu lỗi là một trong những yếu tố thúc đẩy sự phân tách mức độ tinh vi từ phần trước - nhưng khi những dịch vụ đó cần trò chuyện với nhau, thực sự không có gì được cải thiện từ góc độ khả năng chịu lỗi. Khi tách rời các dịch vụ, luôn kiểm tra xem các chức năng có liên kết chặt chẽ và phụ thuộc vào nhau hay không. Nếu có, thì khả năng chịu lỗi tổng thể từ góc độ yêu cầu kinh doanh sẽ không đạt được, và có thể tốt hơn nếu xem xét giữ các dịch vụ lại với nhau.

Hiệu suất tổng thể và khả năng phản hồi là một yếu tố khác thúc đẩy việc tích hợp granular (tập hợp các dịch vụ lại với nhau). Hãy xem xét kịch bản trong Hình 7-13: một dịch vụ khách hàng lớn được chia thành năm dịch vụ riêng biệt (từ A đến E). Trong khi mỗi dịch vụ này có bộ yêu cầu nguyên tử nhất quán riêng, việc lấy tất cả thông tin khách hàng một cách tập hợp từ một yêu cầu API duy nhất vào một giao diện người dùng duy nhất sẽ cần năm lần truy cập riêng biệt khi sử dụng kiểu phối hợp (xem Chương 11 để có giải pháp thay thế cho vấn đề này bằng cách sử dụng điều phối). Giả sử có độ trễ mạng và bảo mật 300 ms cho mỗi yêu cầu, thì yêu cầu đơn lẻ này sẽ phải chịu thêm 1500 ms chỉ riêng về độ trễ! Việc hợp nhất tất cả các dịch vụ này thành một dịch vụ duy nhất sẽ loại bỏ độ trễ, từ đó tăng cường hiệu suất tổng thể và khả năng phản hồi.

Figure 7-13. Too much workflow impacts overall performance and responsiveness

Về tổng thể hiệu suất, sự đánh đổi cho trình điều khiển tích hợp này là cân bằng giữa nhu cầu tách rời một dịch vụ với sự mất mát hiệu suất tương ứng nếu các dịch vụ đó cần giao tiếp với nhau. Một quy tắc tốt là xem xét số lượng yêu cầu cần nhiều dịch vụ giao tiếp với nhau, đồng thời tính đến mức độ quan trọng của những yêu cầu đó cần giao tiếp giữa các dịch vụ. Ví dụ, nếu 30% các yêu cầu cần một quy trình làm việc giữa các dịch vụ để hoàn tất yêu cầu và 70% là hoàn toàn nguyên tử (chỉ dành cho một dịch vụ mà không cần bất kỳ giao tiếp bổ sung nào), thì có thể hợp lý để giữ các dịch vụ tách biệt. Tuy nhiên, nếu tỷ lệ phần trăm bị đảo ngược, thì hãy xem xét việc ghép chúng lại với nhau. Điều này giả định, tất nhiên, rằng hiệu suất tổng thể là quan trọng. Có nhiều sự dễ dãi hơn trong trường hợp chức năng backend, nơi mà người dùng cuối không phải chờ đợi yêu cầu hoàn tất.

Yếu tố hiệu suất khác cần xem xét là mức độ quan trọng của yêu cầu đòi hỏi quy trình làm việc. Hãy xem xét ví dụ trước đó, trong đó 30% các yêu cầu cần một quy trình làm việc giữa các dịch vụ để hoàn thành yêu cầu, và 70% là hoàn toàn nguyên tử. Nếu một yêu cầu quan trọng cần thời gian phản hồi cực nhanh là một phần trong 30%, thì có thể hợp lý hơn khi gộp lại các dịch vụ, mặc dù 70% các yêu cầu hoàn toàn nguyên tử.

Tính đáng tin cậy tổng thể và độ toàn vẹn dữ liệu cũng bị ảnh hưởng bởi sự gia tăng giao tiếp dịch vụ. Xem xét ví dụ trong Hình 7-14: thông tin khách hàng được tách thành năm dịch vụ khách hàng riêng biệt. Trong trường hợp này, việc thêm một khách hàng mới vào hệ thống đòi hỏi sự phối hợp của cả năm dịch vụ khách hàng. Tuy nhiên, như đã giải thích trong một phần trước, mỗi dịch vụ này có giao dịch cơ sở dữ liệu riêng của nó. Lưu ý trong Hình 7-14 rằng các dịch vụ A, B và C đã cam kết một phần dữ liệu khách hàng, nhưng Dịch vụ D thì không thành công.

Figure 7-14. Too much workflow impacts reliability and data integrity

Điều này tạo ra vấn đề về tính nhất quán và tính toàn vẹn của dữ liệu bởi vì một phần dữ liệu khách hàng đã được cam kết và có thể đã được tác động thông qua việc truy xuất thông tin đó từ một quy trình khác hoặc thậm chí là một tin nhắn được gửi từ một trong những dịch vụ đó phát đi hành động dựa trên dữ liệu đó. Trong cả hai trường hợp, dữ liệu đó hoặc phải được hoàn tác thông qua các giao dịch bù đắp hoặc được đánh dấu với một trạng thái cụ thể để biết giao dịch đã dừng lại ở đâu nhằm khởi động lại. Đây là một tình huống rất rối rắm, một tình huống mà chúng tôi mô tả chi tiết trong “Mô hình Giao dịch Saga”. Nếu tính toàn vẹn và tính nhất quán của dữ liệu là quan trọng hoặc chủ chốt cho một hoạt động, có thể là khôn ngoan khi xem xét việc gộp lại những dịch vụ đó.

Shared Code

Mã nguồn chia sẻ là một thực tiễn phổ biến (và cần thiết) trong phát triển phần mềm. Các chức năng như ghi log, bảo mật, tiện ích, định dạng, chuyển đổi, trích xuất, và nhiều thứ khác đều là những ví dụ tốt về mã chia sẻ. Tuy nhiên, mọi thứ có thể trở nên phức tạp khi xử lý mã chia sẻ trong kiến trúc phân tán và đôi khi có thể ảnh hưởng đến độ granularity của dịch vụ.

Mã chia sẻ thường được chứa trong một thư viện chia sẻ, chẳng hạn như tệp JAR trong hệ sinh thái Java, một GEM trong môi trường Ruby, hoặc một DLL trong môi trường .NET, và thường được liên kết với một dịch vụ vào thời điểm biên dịch. Trong khi chúng ta đi sâu vào các mẫu tái sử dụng mã chi tiết trong Chương 8, ở đây chúng tôi chỉ minh họa cách mà mã chia sẻ đôi khi có thể ảnh hưởng đến độ granularity của dịch vụ và có thể trở thành một yếu tố tích hợp độ granularity (tập hợp lại các dịch vụ).

Xem xét tập hợp năm dịch vụ được hiển thị trong Hình 7-15. Mặc dù có thể đã có một trình điều khiển phân tách tốt để chia tách các dịch vụ này, nhưng tất cả chúng đều chia sẻ một mã nguồn chung của chức năng miền (trái ngược với các tiện ích chung hoặc chức năng hạ tầng). Nếu có sự thay đổi xảy ra trong thư viện chung, điều này cuối cùng sẽ yêu cầu sự thay đổi trong các dịch vụ tương ứng sử dụng thư viện chung đó. Chúng tôi nói "cuối cùng" vì việc phiên bản hóa đôi khi có thể được sử dụng với các thư viện chung để cung cấp sự linh hoạt và khả năng tương thích ngược (xem Chương 8). Do đó, tất cả những dịch vụ đã được triển khai riêng này sẽ phải được thay đổi, kiểm tra và triển khai cùng nhau. Trong những trường hợp này, có thể là khôn ngoan khi hợp nhất năm dịch vụ này thành một dịch vụ duy nhất để tránh nhiều lần triển khai, cũng như để chức năng dịch vụ không bị lệch nhau do việc sử dụng các phiên bản khác nhau của một thư viện.

Figure 7-15. A change in shared code requires a coordinated change to all services

Không phải tất cả các việc sử dụng mã chia sẻ đều thúc đẩy sự tích hợp về độ chi tiết. Ví dụ, các chức năng cắt chéo liên quan đến cơ sở hạ tầng như ghi log, kiểm toán, xác thực, ủy quyền và giám sát mà tất cả các dịch vụ cùng sử dụng không phải là một động lực tốt để gộp lại các dịch vụ hoặc thậm chí chuyển về kiến trúc đơn thể. Một số hướng dẫn để xem xét mã chia sẻ như một yếu tố tích hợp độ chi tiết như sau:

Specific shared domain functionality

Chức năng miền chung là mã chia sẻ chứa logic kinh doanh (khác với chức năng liên quan đến hạ tầng). Chúng tôi khuyến nghị xem xét yếu tố này như một bộ phận tích hợp có thể nếu tỷ lệ mã miền chung tương đối cao. Ví dụ, giả sử mã chung (chia sẻ) cho một nhóm chức năng liên quan đến khách hàng (duy trì hồ sơ, duy trì sở thích và thêm hoặc xóa bình luận) chiếm hơn 40% tổng mã nguồn. Phân tách chức năng tập hợp thành các dịch vụ riêng biệt sẽ có nghĩa là gần một nửa mã nguồn nằm trong một thư viện chung chỉ được sử dụng bởi ba dịch vụ đó. Trong ví dụ này, có thể là hợp lý khi xem xét giữ chức năng liên quan đến khách hàng này trong một dịch vụ hợp nhất cùng với mã chia sẻ (đặc biệt nếu mã chia sẻ thay đổi thường xuyên, như đã thảo luận ở phần tiếp theo).

Frequent shared code changes

Bất kể kích thước của thư viện chia sẻ, việc thay đổi thường xuyên các chức năng chia sẻ yêu cầu các thay đổi phối hợp thường xuyên đối với các dịch vụ sử dụng chức năng miền chia sẻ đó. Mặc dù việc phiên bản hóa có thể được sử dụng để giảm thiểu các thay đổi phối hợp, cuối cùng các dịch vụ sử dụng chức năng chia sẻ đó sẽ cần phải áp dụng phiên bản mới nhất. Nếu mã chia sẻ thay đổi thường xuyên, có thể là khôn ngoan khi xem xét hợp nhất các dịch vụ sử dụng mã chia sẻ đó để giúp giảm thiểu sự phối hợp thay đổi phức tạp của nhiều đơn vị triển khai.

Defects that cannot be versioned

Trong khi việc phiên bản hóa có thể giúp hạn chế các thay đổi đồng bộ và cho phép tính tương thích ngược cũng như tính linh hoạt (khả năng phản ứng nhanh với thay đổi), đôi khi một số chức năng kinh doanh nhất định phải được áp dụng cho tất cả các dịch vụ cùng một lúc (chẳng hạn như một lỗi hoặc thay đổi trong quy tắc kinh doanh). Nếu điều này xảy ra thường xuyên, có thể đã đến lúc xem xét việc kết hợp các dịch vụ trở lại với nhau để đơn giản hóa các thay đổi.

Data Relationships

Một sự đánh đổi khác trong sự cân bằng giữa các yếu tố phân tán mức độ chi tiết và các yếu tố tích hợp là mối quan hệ giữa dữ liệu mà một dịch vụ hợp nhất duy nhất sử dụng so với dữ liệu mà các dịch vụ riêng lẻ sẽ sử dụng. Yếu tố tích hợp này giả định rằng dữ liệu có được từ việc tách rời một dịch vụ là không được chia sẻ, mà thay vào đó được hình thành thành các ngữ cảnh giới hạn chặt chẽ trong mỗi dịch vụ để tạo điều kiện cho việc kiểm soát thay đổi và hỗ trợ cho tính sẵn có và độ tin cậy tổng thể.

Xem xét ví dụ trong Hình 7-16: một dịch vụ hợp nhất duy nhất có ba chức năng (A, B và C) và các mối quan hệ bảng dữ liệu tương ứng. Các đường solid chỉ vào các bảng đại diện cho việc ghi vào các bảng (do đó là quyền sở hữu dữ liệu), và các đường chấm chấm chỉ ra từ các bảng đại diện cho quyền truy cập chỉ đọc vào bảng. Việc thực hiện một hoạt động ánh xạ giữa các chức năng và các bảng tiết lộ các kết quả được hiển thị trong Bảng 7-1, trong đó "chủ sở hữu" có nghĩa là ghi (và các truy vấn tương ứng) và "quyền truy cập" có nghĩa là quyền truy cập chỉ đọc vào một bảng không thuộc quyền sở hữu của chức năng đó.

Figure 7-16. The database table relationships of a consolidated service

Giả sử rằng dựa trên một số yếu tố phân tán được nêu trong phần trước, dịch vụ này đã được chia thành ba dịch vụ riêng biệt (mỗi dịch vụ cho một chức năng trong dịch vụ hợp nhất); xem Hình 7-17. Tuy nhiên, việc tách dịch vụ hợp nhất thành ba dịch vụ riêng biệt hiện yêu cầu các bảng dữ liệu tương ứng được gán cho mỗi dịch vụ trong một ngữ cảnh giới hạn.

Lưu ý ở đầu Hình 7-17 rằng Dịch vụ A sở hữu các bảng 1, 2, 4 và 6 như một phần của bối cảnh giới hạn; Dịch vụ B sở hữu bảng 3; và Dịch vụ C sở hữu bảng 5. Tuy nhiên, hãy lưu ý trong sơ đồ rằng mọi thao tác trong Dịch vụ B đều yêu cầu truy cập vào dữ liệu trong bảng 5 (do Dịch vụ C sở hữu), và mọi thao tác trong Dịch vụ C đều yêu cầu truy cập vào dữ liệu trong bảng 3 (do Dịch vụ B sở hữu). Do bối cảnh giới hạn, Dịch vụ B không thể đơn giản gọi ra và truy vấn trực tiếp bảng 5, cũng như Dịch vụ C không thể truy vấn trực tiếp bảng 3.

Để hiểu rõ hơn về ngữ cảnh giới hạn và lý do tại sao Dịch vụ C không thể đơn giản truy cập bảng 3, giả sử Dịch vụ B (nắm giữ bảng 3) quyết định thực hiện một thay đổi trong quy tắc kinh doanh của mình yêu cầu phải loại bỏ một cột khỏi bảng 3. Việc này sẽ làm hỏng Dịch vụ C và bất kỳ dịch vụ nào khác sử dụng bảng 3. Đây là lý do tại sao khái niệm ngữ cảnh giới hạn lại quan trọng trong các kiến trúc phân tán cao như microservices. Để giải quyết vấn đề này, Dịch vụ B sẽ phải yêu cầu Dịch vụ C cung cấp dữ liệu của nó, và Dịch vụ C sẽ phải yêu cầu Dịch vụ B cung cấp dữ liệu của nó, dẫn đến việc giao tiếp qua lại giữa các dịch vụ này, như được mô tả ở dưới hình 7-17.

Figure 7-17. Database table relationships impact service granularity

Dựa trên sự phụ thuộc của dữ liệu giữa các dịch vụ B và C, sẽ là khôn ngoan khi hợp nhất những dịch vụ này thành một dịch vụ duy nhất để tránh các vấn đề về độ trễ, độ tin cậy và khả năng mở rộng liên quan đến việc giao tiếp giữa các dịch vụ này, cho thấy rằng mối quan hệ giữa các bảng có thể ảnh hưởng đến độ chi tiết của dịch vụ. Chúng tôi đã để trình điều khiển tích hợp độ chi tiết này ở lại cuối cùng vì đây là trình điều khiển tích hợp độ chi tiết với ít sự đánh đổi nhất. Mặc dù đôi khi việc di chuyển từ một hệ thống nguyên khối yêu cầu phải cải tiến cách tổ chức dữ liệu, trong hầu hết các trường hợp, không khả thi để tổ chức lại các mối quan hệ thực thể của bảng cơ sở dữ liệu chỉ để tách một dịch vụ. Chúng tôi sẽ đi vào chi tiết về việc tách dữ liệu trong Chương 6.

When to Use

Kỹ thuật sao chép là một phương pháp tốt khi các nhà phát triển có mã tĩnh đơn giản (như chú thích, thuộc tính, tiện ích chung đơn giản, v.v.) mà là một lớp chỉ được tạo ra một lần hoặc mã mà ít có khả năng thay đổi do các lỗi hoặc thay đổi chức năng. Tuy nhiên, như đã đề cập trước đó, chúng tôi khuyến khích khám phá các tùy chọn tái sử dụng mã khác trước khi áp dụng kỹ thuật sao chép mã.

Khi chuyển đổi từ kiến trúc đơn lẻ sang kiến trúc phân tán, chúng tôi cũng nhận thấy rằng kỹ thuật sao chép đôi khi có thể hoạt động cho các lớp tiện ích tĩnh phổ biến. Ví dụ, bằng cách sao chép lớp Utility.cs C# đến tất cả các dịch vụ, mỗi dịch vụ giờ đây có thể loại bỏ (hoặc nâng cao) lớp Utility.cs để phù hợp với nhu cầu cụ thể của mình, do đó loại bỏ mã không cần thiết và cho phép lớp tiện ích phát triển cho từng ngữ cảnh cụ thể (tương tự như kỹ thuật nhánh chiến thuật được mô tả trong Chương 3). Một lần nữa, rủi ro với kỹ thuật này là một lỗi hoặc thay đổi rất khó để lan truyền đến tất cả các dịch vụ vì mã bị sao chép cho mỗi dịch vụ.

Dependency Management and Change Control

Tương tự như độ phân granularity của dịch vụ (được thảo luận trong Chương 7), có những sự đánh đổi liên quan đến độ phân granularity của thư viện chia sẻ. Hai lực đối kháng tạo ra sự đánh đổi với thư viện chia sẻ là quản lý phụ thuộc và kiểm soát thay đổi.

Xem xét thư viện chia sẻ được phân mảnh thô được minh họa trong Hình 8-4. Lưu ý rằng trong khi quản lý phụ thuộc là tương đối đơn giản (mỗi dịch vụ sử dụng một thư viện chia sẻ duy nhất), việc kiểm soát thay đổi thì không. Nếu có sự thay đổi xảy ra ở bất kỳ tệp lớp nào trong thư viện chia sẻ thô, mọi dịch vụ, dù có quan tâm đến sự thay đổi hay không, đều phải cuối cùng áp dụng sự thay đổi đó vì lý do ngưng hỗ trợ phiên bản của thư viện chia sẻ. Điều này buộc phải kiểm thử lại và triển khai lại tất cả các dịch vụ sử dụng thư viện đó, do đó tăng đáng kể phạm vi kiểm thử tổng thể của một thay đổi thư viện chia sẻ.

Figure 8-4. Changes to coarse-grained shared libraries impact multiple services but keep dependencies low

Việc chia mã chung thành các thư viện chia sẻ nhỏ hơn dựa trên chức năng (chẳng hạn như bảo mật, định dạng, chú thích, máy tính, v.v.) thì tốt hơn cho việc kiểm soát thay đổi và khả năng duy trì tổng thể, nhưng không may tạo ra sự lộn xộn về quản lý phụ thuộc. Như được thể hiện trong Hình 8-5, một thay đổi trong lớp chung C7 chỉ ảnh hưởng đến Dịch vụ D và Dịch vụ E, nhưng việc quản lý ma trận phụ thuộc giữa các thư viện chung và dịch vụ nhanh chóng bắt đầu trông như một đống bùn phân tán lớn (hoặc những gì một số người gọi là một khối đơn phân tán).

Figure 8-5. Changes to fine-grained shared libraries impact fewer services but increase dependencies

Lựa chọn độ chi tiết của thư viện chia sẻ có thể không quan trọng nhiều khi chỉ có vài dịch vụ, nhưng khi số lượng dịch vụ tăng lên, các vấn đề liên quan đến kiểm soát thay đổi và quản lý phụ thuộc cũng gia tăng. Chỉ cần tưởng tượng một hệ thống có 200 dịch vụ và 40 thư viện chia sẻ—nó sẽ nhanh chóng trở nên phức tạp và không thể bảo trì.

Xét những đánh đổi giữa kiểm soát thay đổi và quản lý phụ thuộc, lời khuyên của chúng tôi là thường xuyên tránh các thư viện chia sẻ lớn và thô, và cố gắng hướng tới các thư viện nhỏ hơn với phân chia chức năng khi có thể, qua đó ưu tiên kiểm soát thay đổi hơn là quản lý phụ thuộc. Ví dụ, việc tách ra các chức năng tương đối tĩnh như định dạng và bảo mật (xác thực và phân quyền) vào các thư viện chia sẻ riêng biệt sẽ tách biệt mã tĩnh này, do đó giảm quy mô thử nghiệm và các đợt triển khai phiên bản không cần thiết cho các chức năng chia sẻ khác.

Versioning Strategies

Lời khuyên chung của chúng tôi về việc phiên bản thư viện chia sẻ là luôn sử dụng phiên bản! Việc phiên bản hóa các thư viện chia sẻ không chỉ cung cấp tính tương thích ngược mà còn mang lại mức độ linh hoạt cao—khả năng phản ứng nhanh chóng với sự thay đổi.

Để minh họa cho điểm này, hãy xem xét một thư viện chia sẻ chứa các quy tắc xác thực trường chung có tên là Validation.jar, được sử dụng bởi 10 dịch vụ. Giả sử một trong những dịch vụ đó cần thay đổi ngay lập tức một trong các quy tắc xác thực. Bằng cách phiên bản hóa tệp Validation.jar, dịch vụ cần thay đổi có thể ngay lập tức tích hợp phiên bản Validation.jar mới và được triển khai đến môi trường sản xuất ngay lập tức, mà không ảnh hưởng đến 9 dịch vụ còn lại. Nếu không có phiên bản, cả 10 dịch vụ sẽ phải được kiểm tra và triển khai lại khi thực hiện thay đổi thư viện chia sẻ, từ đó làm tăng thời gian và sự phối hợp cho thay đổi thư viện chia sẻ (do đó giảm tính linh hoạt).

Mặc dù những lời khuyên trước đó có thể có vẻ hiển nhiên, nhưng có những đánh đổi và sự phức tạp ẩn chứa trong việc quản lý phiên bản. Thực tế là, việc quản lý phiên bản có thể phức tạp đến nỗi các tác giả của bạn thường xem quản lý phiên bản như một sai lầm thứ chín của điện toán phân tán: “quản lý phiên bản là đơn giản.”

Một trong những phức tạp đầu tiên của việc phiên bản hóa thư viện chia sẻ là việc thông báo một thay đổi phiên bản. Trong một kiến trúc phân tán cao với nhiều đội ngũ, thường rất khó để thông báo một thay đổi phiên bản cho một thư viện chia sẻ. Làm thế nào để các đội khác biết rằng Validation.jar vừa nâng cấp lên phiên bản 1.5? Những thay đổi là gì? Những dịch vụ nào bị ảnh hưởng? Những đội ngũ nào bị ảnh hưởng? Ngay cả với rất nhiều công cụ quản lý thư viện chia sẻ, phiên bản và tài liệu thay đổi (chẳng hạn như JFrog Artifactory), các thay đổi phiên bản vẫn phải được phối hợp và thông báo đến đúng người vào đúng thời điểm.

Một phức tạp khác là việc ngừng hỗ trợ các phiên bản cũ hơn của một thư viện chia sẻ—loại bỏ những phiên bản không còn được hỗ trợ sau một ngày nhất định. Các chiến lược ngừng hỗ trợ dao động từ tùy chỉnh (cho các thư viện chia sẻ riêng lẻ) cho đến toàn cầu (cho tất cả các thư viện chia sẻ). Và, không có gì đáng ngạc nhiên, có những cân nhắc giữa hai cách tiếp cận này.

Gán một chiến lược giảm hạng tùy chỉnh cho từng thư viện chia sẻ thường là cách tiếp cận mong muốn vì các thư viện thay đổi với tốc độ khác nhau. Ví dụ, nếu thư viện chia sẻ Security.jar không thay đổi thường xuyên, thì việc duy trì chỉ hai hoặc ba phiên bản là một chiến lược hợp lý. Tuy nhiên, nếu thư viện chia sẻ Calculators.jar thay đổi hàng tuần, việc duy trì chỉ hai hoặc ba phiên bản có nghĩa là tất cả các dịch vụ sử dụng thư viện chia sẻ đó sẽ phải tích hợp một phiên bản mới hơn hàng tháng (hoặc thậm chí hàng tuần) — gây ra nhiều lần kiểm tra và triển khai lại không cần thiết. Do đó, việc duy trì 10 phiên bản của Calculators.jar sẽ là một chiến lược hợp lý hơn nhiều do tần suất thay đổi. Tuy nhiên, nhược điểm của cách tiếp cận này là ai đó phải duy trì và theo dõi việc giảm hạng cho từng thư viện chia sẻ. Điều này đôi khi có thể là một nhiệm vụ khó khăn và chắc chắn không dành cho những người nhút nhát.

Bởi vì sự thay đổi là biến động giữa các thư viện chia sẻ khác nhau, chiến lược gỡ bỏ toàn cầu, mặc dù đơn giản hơn, lại là một phương pháp kém hiệu quả hơn. Chiến lược gỡ bỏ toàn cầu quy định rằng tất cả các thư viện chia sẻ, bất kể tốc độ thay đổi, sẽ không hỗ trợ nhiều hơn một số phiên bản ngược nhất định (ví dụ: bốn phiên bản). Mặc dù điều này dễ duy trì và quản lý, nhưng nó có thể gây ra sự đảo lộn đáng kể - việc liên tục kiểm tra lại và triển khai lại các dịch vụ - chỉ để duy trì khả năng tương thích với phiên bản mới nhất của một thư viện chia sẻ thường xuyên thay đổi. Điều này có thể khiến các đội ngũ cảm thấy nản lòng và giảm đáng kể tốc độ và năng suất tổng thể của đội.

Bất kể chiến lược loại bỏ nào được sử dụng, các lỗi nghiêm trọng hoặc thay đổi làm hỏng mã chia sẻ đều làm mất hiệu lực bất kỳ loại chiến lược loại bỏ nào, khiến tất cả các dịch vụ phải áp dụng phiên bản mới nhất của một thư viện chia sẻ một lần (hoặc trong một khoảng thời gian rất ngắn). Đây là một lý do khác mà chúng tôi khuyến nghị giữ các thư viện chia sẻ càng chi tiết càng tốt và tránh các thư viện loại lớn như SharedStuff.jar chứa tất cả chức năng chia sẻ trong hệ thống.

Một lời khuyên cuối cùng về phiên bản: hãy tránh sử dụng phiên bản MỚI NHẤT khi chỉ định phiên bản nào của thư viện mà dịch vụ cần. Theo kinh nghiệm của chúng tôi, các dịch vụ sử dụng phiên bản MỚI NHẤT thường gặp vấn đề khi thực hiện các sửa lỗi nhanh hoặc triển khai nóng khẩn cấp vào môi trường sản xuất, vì một số điều trong phiên bản MỚI NHẤT có thể không tương thích với dịch vụ, do đó gây thêm nỗ lực phát triển và kiểm thử cho đội ngũ để phát hành dịch vụ vào sản xuất.

Trong khi kỹ thuật thư viện chia sẻ cho phép thay đổi được phiên bản hóa (do đó cung cấp mức độ linh hoạt cao cho các thay đổi mã chia sẻ), việc quản lý phụ thuộc có thể khó khăn và rắc rối. Bảng 8-2 liệt kê các sự đánh đổi khác nhau liên quan đến kỹ thuật này.

When To Use

Kỹ thuật thư viện chia sẻ là một phương pháp tốt cho các môi trường đồng nhất, nơi thay đổi mã chia sẻ ít đến vừa phải. Khả năng phiên bản (mặc dù đôi khi phức tạp) cho phép mức độ linh hoạt tốt khi thực hiện các thay đổi mã chia sẻ. Bởi vì các thư viện chia sẻ thường được gắn với dịch vụ tại thời điểm biên dịch, các đặc tính vận hành như hiệu suất, khả năng mở rộng và khả năng chịu lỗi không bị ảnh hưởng, và rủi ro làm hỏng các dịch vụ khác do thay đổi mã chung là thấp nhờ vào việc phiên bản.

Change Risk

Việc thay đổi chức năng chia sẻ bằng cách sử dụng kỹ thuật dịch vụ chia sẻ hóa ra là một con dao hai lưỡi. Như được minh họa trong Hình 8-7, việc thay đổi chức năng chia sẻ đơn giản chỉ là việc sửa đổi mã chia sẻ được chứa trong một dịch vụ riêng biệt (như một máy tính giảm giá), redeploy dịch vụ đó, và voilà—các thay đổi giờ đây đã có sẵn cho tất cả các dịch vụ, mà không cần phải kiểm tra lại và redeploy bất kỳ dịch vụ nào khác cần chức năng chia sẻ đó.

Figure 8-7. Shared functionality changes are isolated to only the shared service

Giá mà cuộc sống đơn giản như vậy! Vấn đề, tất nhiên, là sự thay đổi đối với một dịch vụ chung là một thay đổi trong thời gian thực, trái ngược với việc thay đổi dựa trên biên dịch với kỹ thuật thư viện chung. Do đó, một sự thay đổi "đơn giản" trong một dịch vụ chung có thể gây sập toàn bộ hệ thống, như được mô phỏng trong Hình 8-8.

Figure 8-8. Changes to a shared service can break other services at runtime

Điều này tất yếu đưa ra vấn đề phiên bản. Trong kỹ thuật thư viện chia sẻ, việc quản lý phiên bản được thực hiện thông qua các liên kết thời gian biên dịch, làm giảm đáng kể rủi ro liên quan đến việc thay đổi một thư viện chia sẻ. Tuy nhiên, làm thế nào để phiên bản hóa một thay đổi dịch vụ chia sẻ đơn giản?

Phản ứng ngay lập tức, tất nhiên, là sử dụng phiên bản của điểm cuối API—nói cách khác, tạo một điểm cuối mới chứa mỗi thay đổi dịch vụ chia sẻ, như được thể hiện trong Ví dụ 8-3.

app/1.0/discountcalc?orderid=123 app/1.1/discountcalc?orderid=123 app/1.2/discountcalc?orderid=123 app/1.3/discountcalc?orderid=123 latest change -> app/1.4/discountcalc?orderid=123

Sử dụng cách tiếp cận này, mỗi khi một dịch vụ chia sẻ thay đổi, nhóm sẽ tạo một điểm cuối API mới chứa phiên bản mới của URI. Không khó để thấy những vấn đề phát sinh với thực tiễn này. Đầu tiên, các dịch vụ truy cập dịch vụ tính toán giảm giá (hoặc cấu hình tương ứng cho từng dịch vụ) phải thay đổi để chỉ định tới phiên bản chính xác. Thứ hai, khi nào nhóm nên tạo một điểm cuối API mới? Thế còn việc thay đổi một thông điệp lỗi đơn giản thì sao? Còn việc tính toán mới thì sao? Việc phiên phiên bản bắt đầu trở nên phần lớn là chủ quan vào thời điểm này, và các dịch vụ sử dụng dịch vụ chia sẻ vẫn phải thay đổi để chỉ định tới điểm cuối chính xác.

Một vấn đề khác với việc phiên bản hóa điểm cuối API là nó giả định rằng tất cả truy cập vào dịch vụ chia sẻ đều thông qua một cuộc gọi API RESTful đi qua một cổng hoặc thông qua giao tiếp điểm-điểm. Tuy nhiên, trong một số trường hợp, việc truy cập vào dịch vụ chia sẻ thông qua giao tiếp giữa các dịch vụ thường được thực hiện thông qua các giao thức khác như nhắn tin và gRPC (ngoài một cuộc gọi API RESTful). Điều này càng làm phức tạp chiến lược phiên bản cho một thay đổi, khiến cho việc phối hợp các phiên bản giữa nhiều giao thức trở nên khó khăn.

Điều quan trọng là với kỹ thuật dịch vụ chia sẻ, các thay đổi đối với dịch vụ chia sẻ thường mang tính chất thời gian chạy, vì vậy mang nhiều rủi ro hơn so với thư viện chia sẻ. Mặc dù việc quản lý phiên bản có thể giúp giảm thiểu rủi ro này, nhưng nó phức tạp hơn nhiều để áp dụng và quản lý so với thư viện chia sẻ.

Performance

Bởi vì các dịch vụ yêu cầu chức năng chia sẻ phải thực hiện cuộc gọi giữa các dịch vụ đến một dịch vụ chia sẻ, hiệu suất bị ảnh hưởng do độ trễ mạng (và độ trễ bảo mật, giả sử các điểm cuối đến dịch vụ chia sẻ là an toàn). Sự đánh đổi này, như được thể hiện trong Hình 8-9, không tồn tại với kỹ thuật thư viện chia sẻ khi truy cập mã chia sẻ.

Figure 8-9. Shared service introduces network and security latency

Việc sử dụng gRPC có thể giúp giảm bớt một số vấn đề về hiệu suất bằng cách giảm đáng kể độ trễ mạng, cũng như việc sử dụng các giao thức không đồng bộ như nhắn tin. Với nhắn tin, dịch vụ cần chức năng chia sẻ có thể gửi yêu cầu thông qua một hàng đợi yêu cầu, thực hiện các công việc khác, và khi cần thiết, có thể nhận lại kết quả thông qua một hàng đợi phản hồi riêng bằng cách sử dụng ID tương quan (tham khảo Java Message Service, Ấn bản thứ hai của Mark Richards và đồng tác giả (O’Reilly) để biết thêm thông tin về các kỹ thuật nhắn tin).

Scalability

Một nhược điểm khác của kỹ thuật dịch vụ chia sẻ là dịch vụ chia sẻ phải mở rộng theo quy mô của các dịch vụ sử dụng dịch vụ chia sẻ. Điều này đôi khi có thể gây rắc rối trong việc quản lý, đặc biệt là khi nhiều dịch vụ truy cập đồng thời vào cùng một dịch vụ chia sẻ. Tuy nhiên, như được minh họa trong Hình 8-10, kỹ thuật thư viện chia sẻ không gặp phải vấn đề này vì chức năng chia sẻ được chứa trong dịch vụ tại thời điểm biên dịch.

Figure 8-10. Shared services must scale as dependent services scale

Fault Tolerance

Mặc dù các vấn đề về độ tin cậy có thể thường được giảm thiểu thông qua nhiều phiên bản của một dịch vụ, tuy nhiên đây vẫn là một sự đánh đổi cần xem xét khi sử dụng kỹ thuật dịch vụ chia sẻ. Như được minh hoạ trong Hình 8-11, nếu dịch vụ chia sẻ trở nên không khả dụng, các dịch vụ yêu cầu chức năng chia sẻ sẽ không hoạt động cho đến khi dịch vụ chia sẻ sẵn có. Kỹ thuật thư viện chia sẻ không gặp phải vấn đề này vì chức năng chia sẻ được chứa trong dịch vụ tại thời điểm biên dịch, do đó được truy cập thông qua các lệnh gọi phương thức hoặc hàm tiêu chuẩn.

Figure 8-11. Shared services introduce fault-tolerance issues

Kỹ thuật dịch vụ chia sẻ giữ nguyên ngữ cảnh giới hạn và tốt cho mã chia sẻ thay đổi thường xuyên, nhưng các đặc điểm vận hành như hiệu suất, khả năng mở rộng và tính sẵn có bị ảnh hưởng. Bảng 8-3 liệt kê các trade-off khác nhau liên quan đến kỹ thuật này.

When to Use

Kỹ thuật dịch vụ chia sẻ rất hữu ích trong các môi trường đa ngôn ngữ (những môi trường có nhiều ngôn ngữ và nền tảng khác nhau), và cũng khi chức năng chia sẻ có xu hướng thay đổi thường xuyên. Mặc dù những thay đổi trong một dịch vụ chia sẻ thường linh hoạt hơn nhiều so với kỹ thuật thư viện chia sẻ, nhưng cần cẩn thận với các tác động tại thời gian thực và rủi ro đối với các dịch vụ cần chức năng chia sẻ.

When to Use

Mô hình Sidecar và lưới dịch vụ cung cấp một cách sạch sẽ để phân bổ một số loại mối quan tâm cắt ngang trong kiến trúc phân tán, và có thể được sử dụng không chỉ cho sự liên kết hoạt động (xem Chương 14). Nó cung cấp một tương đương kiến trúc với Mẫu Thiết Kế Decorator trong cuốn sách Mẫu Thiết Kế của Gang of Four (Addison Wesley)—nó cho phép kiến trúc sư "trang trí" hành vi trong một kiến trúc phân tán độc lập với khả năng kết nối thông thường.

Reuse via Platforms

Có nhiều bài báo ca ngợi giá trị của các nền tảng trong tổ chức, gần như đến mức phân tán ngữ nghĩa. Tuy nhiên, hầu hết mọi người đều đồng ý rằng nền tảng là mục tiêu mới của sự tái sử dụng trong các tổ chức, có nghĩa là đối với mỗi khả năng miền phân biệt, tổ chức sẽ xây dựng một nền tảng với API được định nghĩa rõ ràng để ẩn đi các chi tiết thực hiện.

Tốc độ thay đổi chậm thúc đẩy lý do này. Như chúng tôi đã thảo luận trong Chương 13, một API có thể được thiết kế để liên kết lỏng lẻo với các caller, cho phép tỷ lệ thay đổi nội bộ về chi tiết thực hiện diễn ra mạnh mẽ mà không làm vỡ API. Điều này, tất nhiên, không bảo vệ tổ chức khỏi những thay đổi về ngữ nghĩa của thông tin mà nó phải truyền giữa các miền, nhưng bằng cách thiết kế cẩn thận về đóng gói và hợp đồng, các kiến trúc sư có thể hạn chế lượng thay đổi gây gãy và sự mong manh trong kiến trúc tích hợp.

Table Split Technique

Kỹ thuật phân tách bảng chia một bảng duy nhất thành nhiều bảng sao cho mỗi dịch vụ sở hữu một phần dữ liệu mà nó chịu trách nhiệm. Kỹ thuật này được mô tả chi tiết trong cuốn sách Refactoring Databases và trên trang web kèm theo.

Để minh họa kỹ thuật chia bảng, hãy xem xét ví dụ bảng Sản phẩm được minh họa trong Hình 9-4. Trong trường hợp này, kiến trúc sư hoặc nhà phát triển sẽ đầu tiên tạo một bảng Hàng tồn kho riêng biệt chứa ID sản phẩm (khóa) và số lượng hàng tồn kho (số lượng mặt hàng có sẵn), trước khi điền dữ liệu vào bảng Hàng tồn kho từ bảng Sản phẩm hiện có, sau đó cuối cùng là xóa cột số lượng hàng tồn kho khỏi bảng Sản phẩm. Mẫu mã nguồn trong Ví dụ 9-1 cho thấy cách mà kỹ thuật này có thể được triển khai bằng cách sử dụng ngôn ngữ định nghĩa dữ liệu (DDL) trong một cơ sở dữ liệu quan hệ điển hình.

CREATE TABLE Inventory ( product_id VARCHAR(10), inv_cnt INT ); INSERT INTO Inventory VALUES (product_id, inv_cnt) AS SELECT product_id, inv_cnt FROM Product; COMMIT; ALTER TABLE Product DROP COLUMN inv_cnt;

Việc chia tách bảng cơ sở dữ liệu chuyển quyền sở hữu chung thành kịch bản sở hữu một bảng đơn: Dịch vụ Danh mục sở hữu dữ liệu trong bảng Sản phẩm, và Dịch vụ Tồn kho sở hữu dữ liệu trong bảng Tồn kho. Tuy nhiên, như shown trong Hình 9-5, kỹ thuật này yêu cầu có sự giao tiếp giữa Dịch vụ Danh mục và Dịch vụ Tồn kho khi sản phẩm được tạo ra hoặc loại bỏ để đảm bảo dữ liệu giữ được sự nhất quán giữa hai bảng.

Figure 9-5. Joint ownership can be addressed by breaking apart the shared table

Ví dụ, nếu một sản phẩm mới được thêm vào, Dịch vụ Danh mục sẽ tạo ra một ID sản phẩm và chèn sản phẩm mới vào bảng Sản phẩm. Sau đó, Dịch vụ Danh mục phải gửi ID sản phẩm mới đó (và có thể là số lượng hàng tồn kho ban đầu) đến Dịch vụ Hàng tồn kho. Nếu một sản phẩm bị xóa, Dịch vụ Danh mục trước tiên sẽ xóa sản phẩm khỏi bảng Sản phẩm, sau đó phải thông báo cho Dịch vụ Hàng tồn kho để xóa dòng hàng tồn kho khỏi bảng Hàng tồn kho.

Việc đồng bộ hóa dữ liệu giữa các bảng phân tách không phải là một vấn đề đơn giản. Liệu việc giao tiếp giữa Dịch vụ Danh mục và Dịch vụ Tồn kho nên là đồng bộ hay bất đồng bộ? Dịch vụ Danh mục nên làm gì khi thêm hoặc xóa sản phẩm và phát hiện rằng Dịch vụ Tồn kho không khả dụng? Đây là những câu hỏi khó để trả lời, và thường bị ảnh hưởng bởi sự đánh đổi giữa tính khả dụng và tính nhất quán mà thường thấy trong các kiến trúc phân tán. Chọn tính khả dụng có nghĩa là quan trọng hơn là Dịch vụ Danh mục luôn có khả năng thêm hoặc xóa sản phẩm, mặc dù một bản ghi tồn kho tương ứng có thể không được tạo trong bảng Tồn kho. Chọn tính nhất quán có nghĩa là quan trọng hơn là hai bảng luôn phải đồng bộ với nhau, điều này sẽ khiến cho thao tác tạo hoặc xóa sản phẩm thất bại nếu Dịch vụ Tồn kho không khả dụng. Vì phân tách mạng là điều cần thiết trong các kiến trúc phân tán, định lý CAP tuyên bố rằng chỉ một trong hai lựa chọn này (tính nhất quán hoặc tính khả dụng) là có thể.

Loại giao thức truyền thông (đồng bộ so với bất đồng bộ) cũng quan trọng khi tách một bảng. Dịch vụ Catalog có cần xác nhận rằng bản ghi Inventory tương ứng được thêm khi tạo sản phẩm mới hay không? Nếu có, thì giao tiếp đồng bộ là cần thiết, cung cấp tính nhất quán dữ liệu tốt hơn nhưng hy sinh hiệu suất. Nếu không cần xác nhận, Dịch vụ Catalog có thể sử dụng giao tiếp bất đồng bộ theo kiểu "bắn và quên", cung cấp hiệu suất tốt hơn nhưng hy sinh tính nhất quán dữ liệu. Có rất nhiều sự đánh đổi cần cân nhắc!

Bảng 9-1 tóm tắt các sự đánh đổi liên quan đến kỹ thuật chia bảng cho quyền sở hữu chung.

Data Domain Technique

Một kỹ thuật khác để sở hữu chung là tạo ra một miền dữ liệu chia sẻ. Điều này được hình thành khi quyền sở hữu dữ liệu được chia sẻ giữa các dịch vụ, từ đó tạo ra nhiều chủ sở hữu cho bảng. Với kỹ thuật này, các bảng được chia sẻ bởi các dịch vụ cùng nhau sẽ được đưa vào cùng một cấu trúc hoặc cơ sở dữ liệu, do đó hình thành một bối cảnh hạn chế rộng hơn giữa các dịch vụ và dữ liệu.

Lưu ý rằng Hình 9-6 trông giống với sơ đồ gốc trong Hình 9-4 với một điểm khác biệt đáng chú ý - sơ đồ miền dữ liệu có bảng Sản phẩm trong một ô riêng biệt bên ngoài ngữ cảnh của mỗi dịch vụ sở hữu. Kỹ thuật vẽ sơ đồ này làm rõ rằng bảng này không thuộc sở hữu hay là phần của ngữ cảnh giới hạn của bất kỳ dịch vụ nào, mà được chia sẻ giữa chúng trong một ngữ cảnh giới hạn rộng hơn.

Figure 9-6. With joint ownership, services can share data by using the data domain technique (shared schema)

Mặc dù việc chia sẻ dữ liệu thường không được khuyến khích trong các kiến trúc phân tán (đặc biệt là với microservices), nhưng điều này giải quyết một số vấn đề về hiệu suất, khả năng sẵn có và tính nhất quán của dữ liệu mà các kỹ thuật sở hữu chung khác gặp phải. Bởi vì các dịch vụ không phụ thuộc vào nhau, Dịch vụ Danh mục có thể tạo hoặc xóa sản phẩm mà không cần phối hợp với Dịch vụ Kho, và Dịch vụ Kho có thể điều chỉnh tồn kho mà không cần Dịch vụ Danh mục. Cả hai dịch vụ hoàn toàn độc lập với nhau.

Tip

Khi chọn kỹ thuật miền dữ liệu, luôn đánh giá lại lý do tại sao cần các dịch vụ riêng biệt vì dữ liệu là chung cho mỗi dịch vụ. Các lý do có thể bao gồm sự khác biệt về khả năng mở rộng, nhu cầu về khả năng chịu lỗi, sự khác biệt về băng thông, hoặc cách ly sự biến động của mã (xem Chương 7).

Thật không may, việc chia sẻ dữ liệu trong một kiến trúc phân tán gây ra một số vấn đề, vấn đề đầu tiên trong số đó là tăng cường nỗ lực cho các thay đổi được thực hiện đối với cấu trúc dữ liệu (chẳng hạn như thay đổi sơ đồ của một bảng). Bởi vì một ngữ cảnh giới hạn rộng hơn được hình thành giữa các dịch vụ và dữ liệu, các thay đổi đối với cấu trúc bảng chia sẻ có thể yêu cầu những thay đổi đó phải được phối hợp giữa nhiều dịch vụ. Điều này dẫn đến việc tăng cường nỗ lực phát triển, phạm vi thử nghiệm và rủi ro triển khai.

Một vấn đề khác với kỹ thuật miền dữ liệu liên quan đến quyền sở hữu dữ liệu là kiểm soát các dịch vụ nào có trách nhiệm ghi vào dữ liệu nào. Trong một số trường hợp, điều này có thể không quan trọng, nhưng nếu việc kiểm soát các hoạt động ghi vào dữ liệu nhất định là quan trọng, thì cần nỗ lực bổ sung để áp dụng các quy tắc quản trị cụ thể nhằm duy trì quyền sở hữu ghi vào bảng hoặc cột cụ thể.

Bảng 9-2 tóm tắt các lợi thế và nhược điểm liên quan đến kỹ thuật miền dữ liệu cho kịch bản sở hữu chung.

Delegate Technique

Một phương pháp thay thế để giải quyết tình huống sở hữu chung là kỹ thuật ủy quyền. Với kỹ thuật này, một dịch vụ được giao quyền sở hữu duy nhất của bảng và trở thành người ủy quyền, trong khi dịch vụ (hoặc dịch vụ) khác giao tiếp với người ủy quyền để thực hiện các cập nhật thay mặt cho mình.

Một trong những thách thức của kỹ thuật ủy quyền là biết dịch vụ nào nên được chỉ định là người ủy quyền (chủ sở hữu duy nhất của bảng). Tùy chọn đầu tiên, được gọi là ưu tiên miền chính, chỉ định quyền sở hữu bảng cho dịch vụ đại diện gần nhất cho miền chính của dữ liệu—nói cách khác, dịch vụ thực hiện hầu hết các thao tác CRUD của thực thể chính cho thực thể cụ thể trong miền đó. Tùy chọn thứ hai, được gọi là ưu tiên đặc điểm hoạt động, chỉ định quyền sở hữu bảng cho dịch vụ cần các đặc điểm kiến trúc hoạt động cao hơn, chẳng hạn như hiệu suất, tính mở rộng, khả năng sẵn sàng và thông lượng.

Để minh họa hai tùy chọn này và các yếu tố đánh đổi tương ứng với mỗi tùy chọn, hãy xem xét kịch bản sở hữu chung giữa Dịch vụ Danh mục và Dịch vụ Tồn kho như được thể hiện trong Hình 9-4. Trong ví dụ này, Dịch vụ Danh mục chịu trách nhiệm tạo, cập nhật và xoá các sản phẩm, cũng như truy xuất thông tin sản phẩm; Dịch vụ Tồn kho chịu trách nhiệm truy xuất và cập nhật số lượng tồn kho sản phẩm cũng như biết khi nào cần bổ sung hàng nếu tồn kho quá thấp.

Với tùy chọn ưu tiên miền chính, dịch vụ thực hiện phần lớn các hoạt động CRUD trên thực thể chính sẽ trở thành chủ sở hữu của bảng. Như được minh họa trong Hình 9-7, vì Dịch vụ Danh mục thực hiện phần lớn các hoạt động CRUD trên thông tin sản phẩm, Dịch vụ Danh mục sẽ được chỉ định là chủ sở hữu duy nhất của bảng. Điều này có nghĩa là dịch vụ Tồn kho phải giao tiếp với Dịch vụ Danh mục để lấy hoặc cập nhật số lượng tồn kho vì nó không sở hữu bảng.

Figure 9-7. Table ownership is assigned to the Catalog service because of domain priority

Giống như kịch bản sở hữu chung đã được mô tả ở trên, kỹ thuật uỷ quyền luôn buộc phải có sự giao tiếp giữa các dịch vụ khác cần cập nhật dữ liệu. Lưu ý rằng trong Hình 9-7, Dịch vụ Quản lý Kho phải gửi các cập nhật hàng tồn kho thông qua một loại giao thức truy cập từ xa nào đó đến Dịch vụ Danh Mục để nó có thể thực hiện các cập nhật và đọc hàng tồn kho thay mặt cho Dịch vụ Quản lý Kho. Giao tiếp này có thể là đồng bộ hoặc không đồng bộ. Như luôn thấy trong kiến trúc phần mềm, cần phải xem xét thêm nhiều phân tích đánh đổi.

Với giao tiếp đồng bộ, Dịch vụ Quản lý hàng tồn kho phải chờ đợi để Dịch vụ Danh mục cập nhật hàng tồn kho, điều này ảnh hưởng đến hiệu suất tổng thể nhưng đảm bảo tính一致 của dữ liệu. Việc sử dụng giao tiếp không đồng bộ để gửi cập nhật hàng tồn kho giúp Dịch vụ Quản lý hàng tồn kho hoạt động nhanh hơn nhiều, nhưng dữ liệu chỉ nhất quán ở mức độ cuối cùng. Hơn nữa, với giao tiếp không đồng bộ, vì có thể xảy ra lỗi trong Dịch vụ Danh mục khi cố gắng cập nhật hàng tồn kho, Dịch vụ Quản lý hàng tồn kho không có đảm bảo rằng hàng tồn kho đã được cập nhật, cũng ảnh hưởng đến tính toàn vẹn của dữ liệu.

Với tùy chọn ưu tiên các đặc tính hoạt động, các vai trò sở hữu sẽ bị đảo ngược vì việc cập nhật tồn kho xảy ra với tốc độ nhanh hơn nhiều so với dữ liệu sản phẩm tĩnh. Trong trường hợp này, quyền sở hữu bảng sẽ được giao cho Dịch vụ Tồn kho, lý do là việc cập nhật tồn kho sản phẩm là một phần của quy trình giao dịch theo thời gian thực thường xuyên hơn trong việc mua sắm sản phẩm, trái ngược với nhiệm vụ hành chính ít xảy ra hơn là cập nhật thông tin sản phẩm hoặc thêm và xoá sản phẩm (xem Hình 9-8).

Với tùy chọn này, việc cập nhật thường xuyên số lượng hàng tồn kho có thể sử dụng các cuộc gọi trực tiếp tới cơ sở dữ liệu thay vì các giao thức truy cập từ xa, từ đó làm cho các hoạt động hàng tồn kho nhanh hơn và đáng tin cậy hơn. Thêm vào đó, dữ liệu có tính biến động cao nhất (số lượng hàng tồn kho) được giữ rất nhất quán.

Figure 9-8. Table ownership is assigned to the Inventory Service because of operational characteristics priority

Tuy nhiên, một vấn đề lớn với sơ đồ được minh họa trong Hình 9-8 là vấn đề trách nhiệm quản lý miền. Dịch vụ Kho hàng chịu trách nhiệm quản lý tồn kho sản phẩm, không phải hoạt động cơ sở dữ liệu (và xử lý lỗi tương ứng) để thêm, xóa và cập nhật thông tin sản phẩm tĩnh. Vì lý do này, chúng tôi thường khuyến nghị tùy chọn ưu tiên miền, và tận dụng các thứ như bộ đệm trong bộ nhớ được nhân bản hoặc bộ đệm phân tán để giúp giải quyết các vấn đề về hiệu suất và khả năng chịu lỗi.

Bất kể dịch vụ nào được chỉ định làm đại diện (chủ sở hữu bảng duy nhất), kỹ thuật đại diện đều có một số bất lợi, lớn nhất là sự liên kết giữa các dịch vụ và nhu cầu giao tiếp giữa các dịch vụ. Điều này dẫn đến các vấn đề khác cho các dịch vụ không phải đại diện, bao gồm việc thiếu giao dịch nguyên tử khi thực hiện các thao tác ghi, hiệu suất thấp do độ trễ mạng và xử lý, và khả năng chịu lỗi thấp. Vì những vấn đề này, kỹ thuật đại diện thường phù hợp hơn cho các kịch bản ghi dữ liệu mà không yêu cầu giao dịch nguyên tử và có thể chịu đựng sự nhất quán cuối cùng thông qua các giao tiếp bất đồng bộ.

Bảng 9-3 tóm tắt những đánh đổi tổng thể của kỹ thuật ủy quyền.

Background Synchronization Pattern

Mô hình đồng bộ hóa nền tảng sử dụng một dịch vụ hoặc quá trình bên ngoài riêng biệt để kiểm tra định kỳ các nguồn dữ liệu và giữ chúng đồng bộ với nhau. Thời gian để các nguồn dữ liệu trở nên nhất quán cuối cùng khi sử dụng mô hình này có thể khác nhau tùy thuộc vào việc quá trình nền được thực hiện như một công việc theo lô chạy vào giữa đêm hay một dịch vụ thức dậy định kỳ (chẳng hạn, mỗi giờ) để kiểm tra tính nhất quán của các nguồn dữ liệu.

Bất kể cách thức quy trình nền được triển khai như thế nào (dữ liệu theo lô hàng đêm hoặc định kỳ), mẫu này thường có thời gian dài nhất để các nguồn dữ liệu trở nên đồng nhất. Tuy nhiên, trong nhiều trường hợp, các nguồn dữ liệu không cần phải được giữ đồng bộ ngay lập tức. Hãy xem xét ví dụ về việc khách hàng hủy đăng ký trong Hình 9-14. Khi một khách hàng hủy đăng ký, thực sự không quan trọng là thông tin hợp đồng hỗ trợ và thông tin thanh toán cho khách hàng đó vẫn tồn tại. Trong trường hợp này, tính đồng nhất cuối cùng thực hiện vào ban đêm là thời gian đủ để đồng bộ dữ liệu.

Một trong những thách thức của mẫu này là quá trình nền được sử dụng để giữ cho tất cả dữ liệu đồng bộ phải biết dữ liệu nào đã thay đổi. Điều này có thể được thực hiện thông qua một luồng sự kiện, một nút kích hoạt cơ sở dữ liệu, hoặc đọc dữ liệu từ các bảng nguồn và điều chỉnh các bảng đích với dữ liệu nguồn. Bất kể kỹ thuật nào được sử dụng để xác định sự thay đổi, quá trình nền phải có kiến thức về tất cả các bảng và nguồn dữ liệu liên quan đến giao dịch.

Hình 9-15 minh họa việc sử dụng mẫu đồng bộ nền cho ví dụ hủy đăng ký của Đội Sysops. Lưu ý rằng vào lúc 11:23:00, khách hàng gửi yêu cầu hủy đăng ký khỏi gói hỗ trợ. Dịch vụ Hồ sơ Khách hàng nhận yêu cầu, xóa dữ liệu và một giây sau (11:23:01) phản hồi lại khách hàng rằng họ đã hủy đăng ký thành công khỏi hệ thống. Sau đó, vào lúc 23:00, quy trình đồng bộ nền theo lô bắt đầu. Quy trình đồng bộ nền phát hiện rằng khách hàng 123 đã bị xóa thông qua việc truyền sự kiện hoặc so sánh thay đổi giữa bảng chính và bảng thứ cấp, và xóa dữ liệu khỏi bảng Hợp đồng và Bảng Thanh toán.

Mẫu này tốt cho khả năng phản hồi tổng thể vì người dùng cuối không phải chờ đợi toàn bộ giao dịch kinh doanh hoàn thành (trong trường hợp này, hủy đăng ký kế hoạch hỗ trợ). Nhưng, thật không may, có một số đánh đổi nghiêm trọng với mô hình nhất quán cuối cùng này.

Figure 9-15. The background synchronization pattern uses an external process to ensure data consistency

Nhược điểm lớn nhất của mô hình đồng bộ hóa nền là nó kết hợp tất cả các nguồn dữ liệu lại với nhau, do đó làm phá vỡ mọi bối cảnh giới hạn giữa dữ liệu và các dịch vụ. Lưu ý trong Hình 9-16 rằng quy trình đồng bộ hóa lô nền phải có quyền ghi cho từng bảng thuộc sở hữu của các dịch vụ tương ứng, có nghĩa là tất cả các bảng đều có quyền sở hữu chung giữa các dịch vụ và quy trình đồng bộ hóa nền.

Sự sở hữu dữ liệu chia sẻ giữa các dịch vụ và quy trình đồng bộ hóa nền tảng đầy rẫy vấn đề, và nhấn mạnh sự cần thiết phải có các bối cảnh ràng buộc chặt chẽ trong một kiến trúc phân tán. Các thay đổi cấu trúc được thực hiện đối với các bảng do mỗi dịch vụ sở hữu (thay đổi tên cột, xóa cột, v.v.) cũng phải được phối hợp với một quy trình nền tảng bên ngoài, khiến việc thay đổi trở nên khó khăn và tốn thời gian.

Ngoài những khó khăn trong việc kiểm soát thay đổi, các vấn đề xảy ra liên quan đến sự lặp lại của logic kinh doanh. Khi xem Hình 9-15, có thể thấy rằng quá trình nền có vẻ khá đơn giản khi thực hiện thao tác DELETE trên tất cả các hàng trong bảng Hợp đồng và Thanh toán chứa khách hàng 123. Tuy nhiên, có thể tồn tại một số quy tắc kinh doanh trong các dịch vụ này cho thao tác cụ thể đó.

Figure 9-16. The background synchronization pattern is coupled to the data sources, therefore breaking the bounded context and data ownership

Ví dụ, khi một khách hàng huỷ đăng ký, các hợp đồng hỗ trợ hiện tại và lịch sử thanh toán của họ sẽ được giữ trong ba tháng trong trường hợp khách hàng quyết định đăng ký lại gói hỗ trợ. Do đó, thay vì xóa các hàng trong những bảng đó, một cột remove_date sẽ được thiết lập với một giá trị dài đại diện cho ngày mà các hàng sẽ bị xóa (một giá trị bằng không trong cột này chỉ ra một khách hàng đang hoạt động). Cả hai dịch vụ đều kiểm tra remove_date hàng ngày để xác định các hàng nào nên bị xóa khỏi các bảng tương ứng của chúng. Câu hỏi là, logic kinh doanh đó nằm ở đâu? Câu trả lời, dĩ nhiên, nằm trong Dịch vụ Hợp đồng Hỗ trợ và Dịch vụ Thanh toán Hóa đơn—ồ, và cũng trong quy trình hàng loạt nền!

Mô hình nhất quán muộn với sự đồng bộ nền tảng không phù hợp cho các kiến trúc phân tán yêu cầu các ngữ cảnh giới hạn chặt chẽ (như microservices) nơi sự gắn kết giữa quyền sở hữu dữ liệu và chức năng là một phần quan trọng của kiến trúc. Các tình huống mà mô hình này hữu ích là các hệ thống không đồng nhất đóng (tự chứa) không giao tiếp với nhau hoặc chia sẻ dữ liệu.

Ví dụ, hãy xem xét một hệ thống nhập đơn hàng cho nhà thầu chấp nhận đơn hàng vật liệu xây dựng, và một hệ thống riêng biệt khác (được triển khai trên nền tảng khác) thực hiện việc lập hóa đơn cho nhà thầu. Khi một nhà thầu đặt hàng cung ứng, một quy trình đồng bộ hóa nền sẽ chuyển những đơn hàng đó sang hệ thống lập hóa đơn để tạo hóa đơn. Khi một nhà thầu thay đổi đơn hàng hoặc hủy bỏ nó, quy trình đồng bộ hóa nền sẽ chuyển những thay đổi đó sang hệ thống lập hóa đơn để cập nhật hóa đơn. Đây là một ví dụ tốt về việc các hệ thống trở nên nhất quán theo thời gian, với đơn hàng của nhà thầu luôn đồng bộ giữa hai hệ thống.

Bảng 9-5 tóm tắt các trao đổi cho mẫu đồng bộ hóa nền tảng để đạt được tính nhất quán cuối cùng.

Orchestrated Request-Based Pattern

Một phương pháp phổ biến để quản lý giao dịch phân tán là đảm bảo rằng tất cả các nguồn dữ liệu được đồng bộ trong suốt quá trình yêu cầu của doanh nghiệp (nói cách khác, trong khi người dùng cuối đang chờ đợi). Phương pháp này được thực hiện thông qua cái gọi là mẫu yêu cầu được tổ chức.

Không giống như mẫu đồng bộ hóa nền tảng trước đó hoặc mẫu dựa trên sự kiện được mô tả trong phần tiếp theo, mẫu dựa trên yêu cầu có tổ chức cố gắng xử lý toàn bộ giao dịch phân tán trong quá trình yêu cầu kinh doanh, do đó yêu cầu một loại nhạc trưởng nào đó để quản lý giao dịch phân tán. Nhạc trưởng, có thể là một dịch vụ hiện có được chỉ định hoặc một dịch vụ riêng biệt mới, chịu trách nhiệm quản lý tất cả công việc cần thiết để xử lý yêu cầu, bao gồm kiến thức về quy trình kinh doanh, kiến thức về các bên tham gia, logic phát đa, xử lý lỗi và quyền sở hữu hợp đồng.

Một cách để thực hiện mẫu này là chỉ định một trong các dịch vụ chính (giả sử có một dịch vụ như vậy) để quản lý giao dịch phân tán. Kỹ thuật này, như được minh họa trong Hình 9-17, chỉ định một trong các dịch vụ đảm nhận vai trò là người điều phối bên cạnh các trách nhiệm khác của nó, trong trường hợp này là Dịch vụ Hồ sơ Khách hàng.

Figure 9-17. The Customer Profile Service takes on the role of an orchestrator for the distributed transaction

Mặc dù phương pháp này tránh khỏi việc cần một dịch vụ quản lý phối hợp riêng biệt, nhưng nó có xu hướng làm quá tải trách nhiệm của dịch vụ được chỉ định làm bộ điều phối giao dịch phân tán. Ngoài vai trò của một bộ điều phối, dịch vụ được chỉ định quản lý giao dịch phân tán còn phải thực hiện các trách nhiệm riêng của nó. Một nhược điểm khác của phương pháp này là nó dễ dẫn đến sự gắn kết chặt chẽ và phụ thuộc đồng bộ giữa các dịch vụ.

Cách tiếp cận mà chúng tôi thường ưa thích khi sử dụng mô hình dựa trên yêu cầu điều phối là sử dụng một dịch vụ điều phối chuyên biệt cho yêu cầu kinh doanh. Cách tiếp cận này, như được minh họa trong Hình 9-18, giải phóng Dịch vụ Hồ sơ Khách hàng khỏi trách nhiệm quản lý giao dịch phân tán và chuyển trách nhiệm đó cho một dịch vụ điều phối riêng biệt.

Chúng tôi sẽ sử dụng phương pháp dịch vụ phối hợp riêng biệt này để mô tả cách mà mô hình nhất quán cuối cùng này hoạt động và những thỏa hiệp tương ứng với mô hình này.

Figure 9-18. A dedicated orchestration service takes on the role of an orchestrator for the distributed transaction

Xin lưu ý rằng vào lúc 11:23:00, khách hàng đã gửi yêu cầu hủy đăng ký khỏi kế hoạch hỗ trợ Sysops Squad. Yêu cầu này được nhận bởi Dịch vụ Điều phối Hủy đăng ký, sau đó chuyển tiếp yêu cầu một cách đồng bộ đến Dịch vụ Hồ sơ Khách hàng để xóa khách hàng khỏi bảng Hồ sơ. Một giây sau, Dịch vụ Hồ sơ Khách hàng gửi lại một sự xác nhận cho Dịch vụ Điều phối Hủy đăng ký, sau đó gửi các yêu cầu song song (qua các luồng hoặc một loại giao thức bất đồng bộ nào đó) đến cả Dịch vụ Hợp đồng Hỗ trợ và Dịch vụ Thanh toán Hóa đơn. Cả hai dịch vụ này xử lý yêu cầu hủy đăng ký và sau đó gửi lại một sự xác nhận một giây sau đó cho Dịch vụ Điều phối Hủy đăng ký, cho biết họ đã hoàn tất việc xử lý yêu cầu. Bây giờ mà tất cả dữ liệu đã đồng bộ, Dịch vụ Điều phối Hủy đăng ký phản hồi lại khách hàng vào lúc 11:23:02 (hai giây sau khi yêu cầu ban đầu được đưa ra), thông báo cho khách hàng biết rằng họ đã hủy đăng ký thành công.

Sự đánh đổi đầu tiên cần lưu ý là phương pháp điều phối thường ủng hộ tính nhất quán của dữ liệu hơn là khả năng phản hồi. Việc thêm một dịch vụ điều phối chuyên dụng không chỉ gây thêm các bước nhảy mạng và lời gọi dịch vụ, mà tùy thuộc vào việc bộ điều phối thực hiện các cuộc gọi theo tuần tự hay song song, thời gian bổ sung sẽ cần thiết cho việc giao tiếp qua lại giữa bộ điều phối và các dịch vụ mà nó đang gọi.

Thời gian phản hồi có thể được cải thiện trong Hình 9-18 bằng cách thực hiện yêu cầu Hồ sơ Khách hàng cùng lúc với các dịch vụ khác, nhưng chúng tôi đã chọn thực hiện hoạt động đó một cách đồng bộ vì lý do xử lý lỗi và tính nhất quán. Ví dụ, nếu khách hàng không thể bị xóa khỏi bảng Hồ sơ do có một khoản phí hóa đơn chưa thanh toán, sẽ không cần phải thực hiện hành động nào khác để đảo ngược các hoạt động trong Dịch vụ Hợp đồng Hỗ trợ và Dịch vụ Thanh toán Hóa đơn. Đây là một ví dụ khác về tính nhất quán so với tính phản hồi.

Ngoài tính linh hoạt, một sự đánh đổi khác với mẫu này là việc xử lý lỗi phức tạp. Trong khi mẫu dựa trên yêu cầu được điều phối có vẻ đơn giản, hãy xem xét điều gì sẽ xảy ra khi khách hàng bị xóa khỏi bảng Hồ sơ và bảng Hợp đồng, nhưng có một lỗi xảy ra khi cố gắng xóa thông tin thanh toán từ bảng Thanh toán, như minh họa trong Hình 9-19. Vì các Dịch vụ Hồ sơ và Hợp đồng Hỗ trợ đã xác nhận các hoạt động của chúng một cách riêng lẻ, nên Dịch vụ Điều phối Hủy bỏ hiện phải quyết định hành động nào sẽ thực hiện trong khi khách hàng đang chờ yêu cầu được xử lý.

1. Liệu người điều phối có nên gửi lại yêu cầu đến Dịch vụ Thanh toán Hóa đơn để thử lại không?

2. Liệu người điều phối có nên thực hiện một giao dịch bồi thường và yêu cầu Dịch vụ Hợp đồng Hỗ trợ và Dịch vụ Hồ sơ Khách hàng hoàn tác các hoạt động cập nhật của chúng không?

3. Liệu người điều phối có nên thông báo cho khách hàng rằng đã xảy ra lỗi và yêu cầu họ chờ một chút trước khi thử lại, trong khi cố gắng khôi phục lại sự nhất quán không?

4. Liệu người điều phối có nên bỏ qua lỗi với hy vọng rằng một quy trình khác sẽ xử lý vấn đề và phản hồi cho khách hàng rằng họ đã được hủy đăng ký thành công không?

Tình huống thực tế này tạo ra một tình huống rối rắm cho bộ điều phối. Bởi vì đây là mẫu nhất quán cuối cùng được sử dụng, không có phương tiện nào khác để chỉnh sửa dữ liệu và đưa mọi thứ trở lại đồng bộ (do đó loại trừ các tùy chọn 3 và 4 trong danh sách trước). Trong trường hợp này, lựa chọn thực sự duy nhất cho bộ điều phối là cố gắng đảo ngược giao dịch phân tán - nói cách khác, thực hiện một cập nhật bồi thường để chèn lại khách hàng trong bảng Hồ sơ và đặt cột remove_date trong bảng Hợp đồng về số không. Điều này sẽ yêu cầu bộ điều phối có tất cả thông tin cần thiết để chèn lại khách hàng, và không có tác động phụ nào xảy ra khi tạo một khách hàng mới (như khởi tạo thông tin thanh toán hoặc hợp đồng hỗ trợ).

Figure 9-19. Error conditions are very hard to address when using the orchestrated request-based pattern

Một phức tạp khác với các giao dịch bù đắp trong kiến trúc phân tán là các lỗi xảy ra trong quá trình bù đắp. Ví dụ, giả sử một giao dịch bù đắp được phát hành cho Dịch vụ Hồ sơ Khách hàng để chèn lại khách hàng, và hoạt động đó đã thất bại. Giờ thì sao? Dữ liệu thực sự đã không còn đồng bộ, và không có dịch vụ hoặc quy trình nào khác xung quanh để sửa chữa vấn đề. Hầu hết các trường hợp như thế này thường đòi hỏi sự can thiệp của con người để sửa chữa các nguồn dữ liệu và đưa chúng trở lại đồng bộ. Chúng tôi sẽ đi vào chi tiết hơn về các giao dịch bù đắp và các saga giao dịch trong "Mẫu Saga Giao dịch".

Bảng 9-6 tóm tắt các đánh đổi cho mô hình yêu cầu có tổ chức dựa trên yêu cầu để đạt được tính nhất quán cuối cùng.

Event-Based Pattern

Mô hình dựa trên sự kiện là một trong những mô hình nhất quán cuối cùng phổ biến và đáng tin cậy nhất cho hầu hết các kiến trúc phân tán hiện đại, bao gồm vi dịch vụ và kiến trúc dựa trên sự kiện. Với mô hình này, các sự kiện được sử dụng kết hợp với mô hình nhắn tin công khai và đăng ký (pub/sub) bất đồng bộ để đăng thông báo sự kiện (chẳng hạn như khách hàng hủy đăng ký) hoặc tin nhắn lệnh (chẳng hạn như hủy đăng ký khách hàng) đến một chủ đề hoặc luồng sự kiện. Các dịch vụ tham gia vào giao dịch phân tán lắng nghe các sự kiện nhất định và phản hồi lại các sự kiện đó.

Thời gian nhất quán cuối cùng thường ngắn để đạt được sự nhất quán dữ liệu nhờ vào tính chất song song và tách biệt của việc xử lý tin nhắn không đồng bộ. Các dịch vụ rất tách biệt với nhau theo mô hình này, và tính nhạy bén là tốt vì dịch vụ kích hoạt sự kiện nhất quán cuối cùng không cần phải chờ đợi quá trình đồng bộ hóa dữ liệu diễn ra trước khi trả thông tin cho khách hàng.

Hình 9-20 minh họa cách mà mô hình dựa trên sự kiện cho tính nhất quán cuối cùng hoạt động. Lưu ý rằng khách hàng đưa ra yêu cầu hủy đăng ký cho Dịch vụ Hồ sơ Khách hàng vào lúc 11:23:00. Dịch vụ Hồ sơ Khách hàng nhận yêu cầu, xóa khách hàng khỏi bảng Hồ sơ, công bố một tin nhắn tới một chủ đề tin nhắn hoặc luồng sự kiện, và trả lại thông tin sau một giây cho khách hàng biết rằng họ đã hủy đăng ký thành công. Xung quanh thời điểm này, cả Dịch vụ Hợp đồng Hỗ trợ và Dịch vụ Thanh toán Hóa đơn đều nhận được sự kiện hủy đăng ký và thực hiện các chức năng cần thiết để hủy đăng ký khách hàng, làm cho tất cả các nguồn dữ liệu cuối cùng nhất quán.

Figure 9-20. The event-based pattern uses asynchronous publish-and-subscribe messaging or event streams to achieve eventual consistency

Đối với các triển khai sử dụng hệ thống nhắn tin theo chủ đề tiêu chuẩn (chẳng hạn như ActiveMQ, RabbitMQ, AmazonMQ, và các hệ thống tương tự), các dịch vụ phản hồi sự kiện phải được thiết lập dưới dạng người đăng ký bền vững để đảm bảo không có thông điệp nào bị mất nếu máy chủ nhắn tin hoặc dịch vụ nhận thông điệp gặp lỗi. Một người đăng ký bền vững tương tự như khái niệm về hàng đợi tồn tại vì người đăng ký (trong trường hợp này là Dịch vụ Hợp đồng Hỗ trợ và Dịch vụ Thanh toán Hóa đơn) không cần phải có mặt tại thời điểm thông điệp được phát hành, và các người đăng ký được đảm bảo nhận được thông điệp ngay khi họ trở nên có sẵn. Trong trường hợp các triển khai truyền phát sự kiện, máy chủ nhắn tin (chẳng hạn như Apache Kafka) phải luôn lưu trữ thông điệp và đảm bảo rằng nó có sẵn trong chủ đề trong một khoảng thời gian hợp lý.

Những lợi ích của mô hình dựa trên sự kiện là khả năng phản hồi, tính kịp thời của sự nhất quán dữ liệu và sự tách rời dịch vụ. Tuy nhiên, giống như tất cả các mô hình nhất quán cuối cùng, sự đánh đổi chính của mô hình này là xử lý lỗi. Nếu một trong các dịch vụ (ví dụ, Dịch vụ Thanh toán Hóa đơn được minh họa trong Hình 9-20) không sẵn có, thực tế rằng nó là một người đăng ký bền bỉ có nghĩa là cuối cùng nó sẽ nhận và xử lý sự kiện khi nó trở nên sẵn có. Tuy nhiên, nếu dịch vụ đang xử lý sự kiện và gặp sự cố, mọi chuyện trở nên phức tạp nhanh chóng.

Hầu hết các trình xử lý tin nhắn sẽ cố gắng gửi tin nhắn một số lần nhất định, và sau nhiều lần không thành công từ phía người nhận, trình xử lý sẽ gửi tin nhắn đến hàng đợi thư chết (DLQ). Đây là một địa điểm có thể cấu hình để lưu trữ sự kiện cho đến khi một quy trình tự động đọc tin nhắn và cố gắng sửa chữa vấn đề. Nếu không thể sửa chữa theo chương trình, tin nhắn sẽ thường được gửi đến một người để xử lý thủ công.

Bảng 9-7 liệt kê các sự đánh đổi cho mẫu dựa trên sự kiện nhằm đạt được tính nhất quán cuối cùng.

Workflow State Management

Hầu hết các luồng công việc đều bao gồm trạng thái tạm thời về tình trạng của luồng công việc: những yếu tố nào đã thực thi, những yếu tố nào còn lại, thứ tự, điều kiện lỗi, các lần thử lại, và những điều khác. Đối với các giải pháp được phối hợp, người sở hữu trạng thái luồng công việc rõ ràng là bộ điều phối (mặc dù một số giải pháp kiến trúc tạo ra các bộ điều phối không trạng thái để có quy mô lớn hơn). Tuy nhiên, đối với việc phối hợp, không có người sở hữu trạng thái luồng công việc rõ ràng nào. Nhiều tùy chọn phổ biến để quản lý trạng thái trong việc phối hợp; dưới đây là ba tùy chọn phổ biến.

Đầu tiên, mẫu Front Controller đặt trách nhiệm về trạng thái lên dịch vụ được gọi đầu tiên trong chuỗi trách nhiệm, trong trường hợp này là Dịch vụ Đặt Hàng. Nếu dịch vụ đó chứa thông tin về cả đơn hàng và trạng thái của quy trình làm việc, một số dịch vụ miền phải có một liên kết giao tiếp để truy vấn và cập nhật trạng thái đơn hàng, như minh họa trong Hình 11-13.

Figure 11-13. In choreography, a Front Controller is a domain service that owns workflow state in addition to domain behavior

Trong kịch bản này, một số dịch vụ phải giao tiếp trở lại với Dịch vụ Đặt hàng để cập nhật trạng thái của đơn hàng, vì nó là chủ sở hữu trạng thái. Mặc dù điều này đơn giản hóa quy trình làm việc, nhưng nó làm tăng chi phí giao tiếp và làm cho Dịch vụ Đặt hàng trở nên phức tạp hơn so với một dịch vụ chỉ xử lý hành vi miền. Trong khi mẫu Front Controller có một số đặc điểm thuận lợi, nó cũng có những đánh đổi, như được chỉ ra trong Bảng 11-2.

Một cách thứ hai để một kiến trúc sư quản lý trạng thái giao dịch là không lưu trữ bất kỳ trạng thái công việc tạm thời nào, mà dựa vào việc truy vấn các dịch vụ cá nhân để xây dựng một ảnh chụp thời gian thực. Điều này được gọi là điệu nhảy không trạng thái. Trong khi điều này đơn giản hóa trạng thái của dịch vụ đầu tiên, nó làm tăng đáng kể chi phí mạng liên quan đến việc trao đổi giữa các dịch vụ để xây dựng một ảnh chụp trạng thái. Ví dụ, hãy xem xét một quy trình làm việc như con đường điệu nhảy vui vẻ đơn giản trong Hình 11-7 mà không có trạng thái bổ sung. Nếu một khách hàng muốn biết trạng thái đơn hàng của họ, kiến trúc sư phải xây dựng một quy trình làm việc truy vấn trạng thái của từng dịch vụ miền để xác định trạng thái đơn hàng mới nhất. Mặc dù điều này tạo ra một giải pháp linh hoạt cao, nhưng việc tái xây dựng trạng thái có thể phức tạp và tốn kém về các đặc điểm kiến trúc vận hành như khả năng mở rộng và hiệu suất. Điệu nhảy không trạng thái đánh đổi hiệu suất cao để lấy kiểm soát quy trình làm việc, như được minh họa trong Bảng 11-3.

Một giải pháp thứ ba sử dụng kết nối dấu hiệu (được mô tả chi tiết hơn trong “Kết nối dấu hiệu cho Quản lý Quy trình làm việc”), lưu trữ trạng thái quy trình làm việc bổ sung trong hợp đồng tin nhắn được gửi giữa các dịch vụ. Mỗi dịch vụ miền cập nhật phần của mình trong trạng thái tổng thể và chuyển nó cho dịch vụ tiếp theo trong chuỗi trách nhiệm. Do đó, bất kỳ người tiêu dùng nào của hợp đồng đó có thể kiểm tra trạng thái của quy trình làm việc mà không cần truy vấn mỗi dịch vụ.

Đây là một giải pháp tạm thời, vì nó vẫn chưa cung cấp một nơi duy nhất cho người dùng để truy vấn trạng thái của quy trình làm việc đang diễn ra. Tuy nhiên, nó cung cấp cách để truyền trạng thái giữa các dịch vụ như một phần của quy trình làm việc, cung cấp cho mỗi dịch vụ bối cảnh bổ sung có thể hữu ích. Như trong tất cả các tính năng của kiến trúc phần mềm, sự kết nối đóng dấu có những đặc điểm tốt và xấu, được thể hiện trong Bảng 11-4.

Trong Chương 13, chúng tôi thảo luận về cách các hợp đồng có thể giảm hoặc tăng cường sự kết nối quy trình làm việc trong các giải pháp được phối hợp.

Những lợi thế của phong cách giao tiếp qua vũ đạo bao gồm:

Responsiveness

Phong cách giao tiếp này có ít điểm nghẽn đơn, do đó cung cấp nhiều cơ hội cho sự song song hóa hơn.

Scalability

Tương tự như khả năng phản hồi, việc thiếu các điểm phối hợp như nhạc trưởng cho phép việc mở rộng độc lập hơn.

Fault tolerance

Việc thiếu một trình điều phối đơn lẻ cho phép kiến trúc sư tăng cường khả năng chịu lỗi bằng cách sử dụng nhiều phiên bản.

Service decoupling

Không có bộ điều phối đồng nghĩa với việc giảm sự liên kết.

Những nhược điểm của phong cách giao tiếp vũ đạo bao gồm:

Distributed workflow

Không có người quản lý quy trình nào khiến việc quản lý lỗi và các điều kiện ranh giới trở nên khó khăn hơn.

State management

Không có người đại diện nhà nước tập trung cản trở quản lý nhà nước đang diễn ra.

Error handling

Xử lý lỗi trở nên khó khăn hơn mà không có người điều phối vì các dịch vụ miền phải có nhiều kiến thức về quy trình làm việc hơn.

Recoverability

Tương tự, khả năng phục hồi trở nên khó khăn hơn mà không có một người điều phối để thực hiện các nỗ lực thử lại và khắc phục khác.

Giống như "Phong cách giao tiếp lập trình", điệu nhảy có một số lợi ích và bất lợi, thường là trái ngược nhau, được tóm tắt trong Bảng 11-5.

State Owner and Coupling

Như minh họa trong Hình 11-13, quyền sở hữu nhà nước thường nằm ở một vị trí nào đó, hoặc trong một trung gian chính thức hoạt động như một người điều phối, hoặc một bộ điều khiển chính trong một giải pháp được phối hợp. Trong giải pháp phối hợp, việc loại bỏ trung gian buộc các dịch vụ phải giao tiếp ở mức độ cao hơn. Đây có thể là một sự đánh đổi hoàn toàn hợp lý. Ví dụ, nếu một kiến trúc sư có một quy trình làm việc cần quy mô lớn hơn và thường có ít điều kiện lỗi, thì việc đánh đổi giữa quy mô lớn hơn của việc phối hợp với độ phức tạp của xử lý lỗi có thể là điều đáng giá.

Tuy nhiên, khi độ phức tạp của quy trình làm việc tăng lên, nhu cầu về một bộ điều phối cũng tăng theo tỷ lệ, như được minh họa trong Hình 11-14.

Hơn nữa, càng có nhiều độ phức tạp ngữ nghĩa trong một quy trình làm việc, thì vai trò của điều phối viên càng trở nên thiết thực. Hãy nhớ rằng, việc kết nối thực hiện không thể cải thiện kết nối ngữ nghĩa, chỉ có thể làm cho nó tồi tệ hơn.

Cuối cùng, điểm tối ưu cho biên đạo nằm ở những quy trình làm việc cần tính phản hồi và khả năng mở rộng, và hoặc không có các kịch bản lỗi phức tạp hoặc chúng xảy ra không thường xuyên. Phong cách giao tiếp này cho phép thông lượng cao; nó được sử dụng bởi các mẫu liên kết động như “Mẫu Câu Chuyện Điện Thoại”, “Mẫu Câu Chuyện Du Hành Thời Gian”, và “Mẫu Câu Chuyện Tuyển Tập”. Tuy nhiên, nó cũng có thể dẫn đến việc triển khai cực kỳ khó khăn khi các yếu tố khác được đưa vào, dẫn đến “Mẫu Câu Chuyện Kinh Hoàng”.

Figure 11-14. As the complexity of the workflow rises, orchestration becomes more useful

Mặt khác, điều phối (orchestration) phù hợp nhất cho các quy trình làm việc phức tạp bao gồm điều kiện ranh giới và lỗi. Trong khi kiểu này không cung cấp nhiều khả năng mở rộng như biên đạo (choreography), nó giảm bớt độ phức tạp trong hầu hết các trường hợp. Kiểu giao tiếp này xuất hiện trong các mẫu "Epic Saga", "Fairy Tale Saga", "Fantasy Fiction Saga" và "Parallel Saga".

Sự phối hợp là một trong những lực chính tạo ra độ phức tạp cho các kiến trúc sư khi xác định cách tốt nhất để giao tiếp giữa các microservices. Tiếp theo, chúng ta sẽ khảo sát cách mà lực này giao thoa với một lực chính khác, sự nhất quán.

Epic Saga^(sao) Pattern

Loại hình giao tiếp này là mô hình saga “truyền thống” như nhiều kiến trúc sư hiểu, còn được gọi là Saga Dàn Hợp Tác vì loại hình phối hợp của nó. Các mối quan hệ không gian của nó xuất hiện trong Hình 12-2.

Mô hình này sử dụng giao tiếp đồng bộ, tính nhất quán nguyên tử và sự phối hợp có tổ chức. Mục tiêu của kiến trúc sư khi chọn mô hình này giống với hành vi của các hệ thống đơn thể - thực tế, nếu một hệ thống đơn thể được thêm vào sơ đồ này trong Hình 12-2, nó sẽ là gốc (0, 0, 0), hoàn toàn thiếu phân phối. Do đó, kiểu giao tiếp này rất quen thuộc với các kiến trúc sư và nhà phát triển của các hệ thống giao dịch truyền thống.

Figure 12-2. The Epic Saga^(sao) pattern’s dynamic coupling (communication, consistency, coordination) relationships

Biểu diễn đồng cấu của mẫu Epic Saga xuất hiện trong Hình 12-3.

Figure 12-3. The isomorphic communication illustration of the Epic Saga^(sao) pattern

Ở đây, một dịch vụ điều phối điều phối một quy trình công việc bao gồm các bản cập nhật cho ba dịch vụ, được dự kiến sẽ xảy ra theo cách giao dịch - hoặc tất cả ba cuộc gọi thành công hoặc không cuộc gọi nào thành công. Nếu một trong các cuộc gọi thất bại, thì tất cả đều thất bại và trở lại trạng thái trước đó. Một kiến trúc sư có thể giải quyết vấn đề phối hợp này theo nhiều cách, tất cả đều phức tạp trong các kiến trúc phân tán. Tuy nhiên, các giao dịch như vậy giới hạn sự lựa chọn cơ sở dữ liệu và có những chế độ thất bại nổi tiếng.

Nhiều kiến trúc sư mới vào nghề hoặc còn thiếu kinh nghiệm thường tin rằng, vì một mẫu tồn tại cho một vấn đề, nó đại diện cho một giải pháp rõ ràng. Tuy nhiên, mẫu đó chỉ là sự nhận diện sự phổ biến, chứ không phải khả năng giải quyết. Các giao dịch phân tán cung cấp một ví dụ xuất sắc cho hiện tượng này—các kiến trúc sư quen với việc mô hình hóa giao dịch trong các hệ thống không phân tán đôi khi tin rằng việc chuyển khả năng đó sang thế giới phân tán chỉ là một thay đổi gia tăng. Tuy nhiên, các giao dịch trong kiến trúc phân tán gặp phải một số thách thức, những thách thức này trở nên tồi tệ hơn một cách tỷ lệ thuận với độ phức tạp của sự kết hợp ngữ nghĩa của vấn đề.

Xem xét một triển khai phổ biến của mẫu Epic Saga, sử dụng các giao dịch bồi thường. Một cập nhật bồi thường là một hành động đảo ngược một hành động ghi dữ liệu mà một dịch vụ khác đã thực hiện (chẳng hạn như đảo ngược một cập nhật, chèn lại một hàng đã bị xóa trước đó, hoặc xóa một hàng đã được chèn trước đó) trong quá trình thực hiện phạm vi giao dịch phân tán. Trong khi các cập nhật bồi thường cố gắng đảo ngược các thay đổi nhằm đưa các nguồn dữ liệu phân tán trở lại trạng thái ban đầu của chúng trước khi bắt đầu giao dịch phân tán, chúng lại chứa đựng nhiều vấn đề phức tạp, thách thức và sự đánh đổi.

Một mô hình giao dịch bù đắp gán một dịch vụ để giám sát tính hoàn chỉnh của giao dịch của một yêu cầu, như được trình bày trong Hình 12-4.

Figure 12-4. A successful orchestrated transactional Epic Saga using a compensating transaction

Tuy nhiên, cũng như nhiều vấn đề trong kiến trúc, các điều kiện lỗi gây ra khó khăn. Trong một khuôn khổ giao dịch bù đắp, người trung gian theo dõi sự thành công của các cuộc gọi và phát hành các cuộc gọi bù đắp tới các dịch vụ khác nếu một hoặc nhiều yêu cầu thất bại, như được trình bày trong Hình 12-5.

Figure 12-5. When an error occurs, a mediator must send compensating requests to other services

Một môi giới vừa chấp nhận các yêu cầu vừa trung gian hóa quy trình công việc, và các cuộc gọi đồng bộ đến hai dịch vụ đầu tiên thành công. Tuy nhiên, khi cố gắng gọi đến dịch vụ cuối cùng, cuộc gọi thất bại (do có thể nhiều lý do cả về miền lẫn hoạt động). Vì mục tiêu của Epic Saga là tính nhất quán nguyên tử, người môi giới phải sử dụng các giao dịch bồi thường và yêu cầu hai dịch vụ còn lại hoàn tác hoạt động trước đó, đưa trạng thái tổng thể trở về như trước khi giao dịch bắt đầu.

Mẫu này được sử dụng rộng rãi: nó mô hình hóa hành vi quen thuộc và có tên mẫu đã được thiết lập rõ ràng. Nhiều kiến trúc sư mặc định theo mẫu Epic Saga vì nó cảm thấy quen thuộc với các kiến trúc đơn khối, kết hợp với yêu cầu (đôi khi là sự đòi hỏi) từ các bên liên quan rằng các thay đổi trạng thái phải được đồng bộ hóa, bất chấp các hạn chế kỹ thuật. Tuy nhiên, nhiều mẫu liên kết động lượng khác có thể cung cấp một bộ điều chỉnh giao dịch tốt hơn.

Lợi thế rõ ràng của Epic Saga là sự phối hợp giao dịch mô phỏng các hệ thống đơn khối, kết hợp với người sở hữu quy trình rõ ràng được đại diện qua một bộ điều phối. Tuy nhiên, những bất lợi là đa dạng. Thứ nhất, việc điều phối cộng với tính giao dịch có thể ảnh hưởng đến các đặc điểm kiến trúc hoạt động như hiệu suất, quy mô, tính đàn hồi, v.v.—người điều phối phải đảm bảo rằng tất cả các bên tham gia trong giao dịch đều thành công hoặc thất bại, gây ra các nút thắt thời gian. Thứ hai, các mẫu khác nhau được sử dụng để triển khai tính giao dịch phân tán (chẳng hạn như các giao dịch bồi thường) dễ bị ảnh hưởng bởi nhiều chế độ thất bại và điều kiện biên khác nhau, cùng với việc thêm độ phức tạp vốn có thông qua các thao tác hoàn tác. Các giao dịch phân tán gặp rất nhiều khó khăn và do đó tốt nhất là nên tránh nếu có thể.

Mô hình Truyền thuyết Vĩ đại có các đặc điểm sau đây:

Coupling level

Mẫu này thể hiện mức độ kết nối cực kỳ cao trên tất cả các chiều có thể có: giao tiếp đồng bộ, tính nhất quán nguyên tử và phối hợp có tổ chức - thực tế đây là mẫu kết nối cao nhất trong danh sách. Điều này không gây ngạc nhiên, vì nó mô hình hóa hành vi của giao tiếp trong hệ thống monolithic được kết nối chặt chẽ, nhưng tạo ra một số vấn đề trong kiến trúc phân tán.

Complexity level

Các điều kiện lỗi và các phối hợp chặt chẽ khác được thêm vào yêu cầu về tính nguyên tử làm tăng độ phức tạp cho kiến trúc này. Các cuộc gọi đồng bộ mà kiến trúc này sử dụng làm giảm bớt một số phức tạp, vì các kiến trúc sư không phải lo lắng về các điều kiện tranh chấp và tình trạng chết trong quá trình gọi.

Responsiveness/availability

Sự điều phối tạo ra một nút thắt cổ chai, đặc biệt khi nó cũng phải phối hợp tính nguyên tử của giao dịch, điều này làm giảm khả năng phản hồi. Mô hình này sử dụng các cuộc gọi đồng bộ, ảnh hưởng thêm đến hiệu suất và khả năng phản hồi. Nếu bất kỳ dịch vụ nào không có sẵn hoặc xảy ra lỗi không thể khôi phục, mô hình này sẽ thất bại.

Scale/elasticity

Tương tự như sự linh hoạt, nút thắt và sự phối hợp cần thiết để thực hiện mô hình này khiến cho việc mở rộng quy mô và các mối quan tâm về vận hành khác trở nên khó khăn.

Trong khi Epic Saga rất phổ biến nhờ sự quen thuộc, nó đã tạo ra một số thách thức, cả từ góc độ thiết kế lẫn đặc điểm vận hành, như được trình bày trong Bảng 12-2.

Rất may, các kiến trúc sư không cần phải mặc định vào các mẫu mà, mặc dù có vẻ quen thuộc, lại tạo ra sự phức tạp ngẫu nhiên - có nhiều mẫu khác nhau với các bộ thỏa hiệp khác nhau. Hãy tham khảo "Huyền thoại Đội Sysops: Giao dịch Nguyên tử và Cập nhật Bù" để có một ví dụ cụ thể về Huyền thoại Huyền thoại và một số thách thức phức tạp mà nó mang lại (cũng như cách giải quyết những thách thức đó).

Phone Tag Saga^(sac) Pattern

Mô hình Phone Tag Saga thay đổi một trong những khía cạnh của Epic Saga, chuyển đổi sự phối hợp từ được điều phối sang được biên đạo; sự thay đổi này được minh họa trong Hình 12-6.

Figure 12-6. The Phone Tag pattern utilizes loosely coupled communication

Tên mẫu là Phone Tag vì nó giống với một trò chơi trẻ em nổi tiếng được gọi là Telephone ở Bắc Mỹ: trẻ em tạo thành một vòng tròn, và một người thì thầm một bí mật cho người tiếp theo, người này tiếp tục truyền đạt cho người tiếp theo, cho đến khi phiên bản cuối cùng được nói ra bởi người cuối cùng. Trong Hình 12-6, sự phối hợp được ưa chuộng hơn so với sự chỉ huy, tạo ra sự thay đổi tương ứng trong cấu trúc giao tiếp như được thể hiện trong Hình 12-7.

Figure 12-7. Because of a lack of orchestration, each participant must coordinate status

Mô hình Phone Tag Saga có tính chất nguyên tử nhưng cũng có sự phụ thuộc, nghĩa là kiến trúc sư không chỉ định một bộ điều khiển chính thức. Tuy nhiên, tính nguyên tử yêu cầu một mức độ phối hợp nào đó. Trong Hình 12-7, dịch vụ được gọi ban đầu trở thành điểm phối hợp (đôi khi được gọi là bộ điều khiển phía trước). Khi nó hoàn thành công việc của mình, nó sẽ chuyển yêu cầu cho dịch vụ tiếp theo trong quy trình làm việc, tiếp tục cho đến khi quy trình thành công. Tuy nhiên, nếu xảy ra điều kiện lỗi, mỗi dịch vụ phải có logic tích hợp để gửi các yêu cầu bù lại dọc theo chuỗi.

Bởi vì mục tiêu kiến trúc là tính nguyên tử giao dịch, logic để phối hợp tính nguyên tử đó phải tồn tại ở đâu đó. Do đó, các dịch vụ miền phải chứa nhiều logic hơn về ngữ cảnh quy trình mà chúng tham gia, bao gồm cả xử lý lỗi và định tuyến. Đối với các quy trình phức tạp, bộ điều khiển phía trước trong mẫu này sẽ trở nên phức tạp như hầu hết các trình điều phối, làm giảm sức hấp dẫn và tính ứng dụng của mẫu này. Do đó, mẫu này thường được sử dụng cho các quy trình đơn giản cần quy mô lớn hơn, nhưng có thể ảnh hưởng đến hiệu suất.

Cách thức phối hợp so với kiến trúc điều phối cải thiện các đặc điểm kiến trúc hoạt động như khả năng mở rộng? Việc sử dụng phối hợp ngay cả với giao tiếp đồng bộ giúp giảm thiểu các nút thắt—trong các điều kiện không có lỗi, dịch vụ cuối cùng trong quy trình làm việc có thể trả kết quả, cho phép lưu lượng cao hơn và ít điểm nghẽn hơn. Hiệu suất cho các quy trình làm việc bình thường có thể nhanh hơn trong một Epic Saga do thiếu sự phối hợp. Tuy nhiên, trong các điều kiện lỗi sẽ chậm hơn nhiều mà không có người trung gian—mỗi dịch vụ phải giải phóng chuỗi gọi, điều này cũng làm tăng độ kết nối giữa các dịch vụ.

Thông thường, Phone Tag Saga cung cấp quy mô tốt hơn một chút so với Epic Saga do không có một bên trung gian, điều này đôi khi có thể trở thành một nút thắt hạn chế. Tuy nhiên, mẫu này cũng thể hiện hiệu suất thấp hơn cho các điều kiện lỗi và những độ phức tạp của quy trình làm việc khác—không có bên trung gian, quy trình làm việc phải được giải quyết thông qua giao tiếp giữa các dịch vụ, điều này ảnh hưởng đến hiệu suất.

Một đặc điểm tốt của kiến trúc không điều phối là không có sự đơn đôi trong việc kết nối, tức là không có một nơi duy nhất mà luồng công việc gắn kết với nhau. Mặc dù mẫu này sử dụng các yêu cầu đồng bộ, nhưng có ít điều kiện chờ hơn cho các luồng công việc diễn ra thuận lợi, cho phép mở rộng quy mô cao hơn. Nói chung, việc giảm sự kết nối sẽ tăng khả năng mở rộng.

Với khả năng mở rộng được cải thiện do thiếu sự điều phối, đi kèm là sự phức tạp gia tăng của các dịch vụ miền để quản lý các mối quan tâm về quy trình làm việc bên cạnh trách nhiệm chính của chúng. Đối với các quy trình làm việc phức tạp, sự phức tạp gia tăng và giao tiếp giữa các dịch vụ có thể khiến các kiến trúc sư trở lại với việc điều phối và các khoản đánh đổi của nó.

Cuộc chiến điện thoại có một sự kết hợp tính năng khá hiếm — nói chung, nếu một kiến trúc sư chọn phối hợp, họ cũng chọn bất đồng bộ. Tuy nhiên, trong một số trường hợp mà một kiến trúc sư có thể chọn sự kết hợp này thay vào đó: các gọi đồng bộ đảm bảo rằng mỗi dịch vụ miền hoàn thành phần của nó trong quy trình trước khi gọi đến cái tiếp theo, loại bỏ các điều kiện tranh chấp. Nếu các điều kiện lỗi dễ giải quyết, hoặc các dịch vụ miền có thể sử dụng tính idempotence và thực hiện lại, thì các kiến trúc sư có thể xây dựng quy mô song song cao hơn bằng cách sử dụng mẫu này so với Epic Saga.

Mô hình Telephone Tag Saga có các đặc điểm sau:

Coupling level

Mô hình này giảm bớt một trong những chiều liên kết của mô hình Epic Saga, sử dụng một quy trình công việc được phối hợp thay vì được điều phối. Do đó, mô hình này ít bị liên kết hơn một chút, nhưng vẫn giữ yêu cầu giao dịch giống nhau, có nghĩa là sự phức tạp của quy trình làm việc phải được phân phối giữa các dịch vụ miền.

Complexity level

Mô hình này phức tạp hơn nhiều so với Epic Saga; độ phức tạp trong mô hình này tăng lên tỷ lệ thuận với độ phức tạp ngữ nghĩa của quy trình: quy trình càng phức tạp, càng nhiều logic phải xuất hiện trong mỗi dịch vụ để bù đắp cho sự thiếu hụt của bộ điều phối. Mặt khác, một kiến trúc sư có thể thêm thông tin quy trình vào chính các tin nhắn như một hình thức gắn kết đóng dấu (xem “Gắn Kết Đóng Dấu cho Quản Lý Quy Trình”) để duy trì trạng thái, nhưng việc này lại làm tăng thêm bối cảnh phụ thuộc mà mỗi dịch vụ cần.

Responsiveness/availability

Ít sự điều phối thường dẫn đến khả năng phản hồi tốt hơn, nhưng các điều kiện lỗi trong mô hình này trở nên khó khăn hơn để mô hình hóa mà không có người điều phối, đòi hỏi nhiều sự phối hợp thông qua các callback và các hoạt động tốn thời gian khác.

Scale/elasticity

Thiếu sự phối hợp dẫn đến ít điểm nghẽn hơn, thường làm tăng khả năng mở rộng, nhưng chỉ một chút. Mô hình này vẫn sử dụng sự kết nối chặt chẽ xung quanh hai trong ba chiều, vì vậy khả năng mở rộng không phải là một điểm nổi bật, đặc biệt nếu các điều kiện lỗi xảy ra thường xuyên.

Các xếp hạng cho Phone Tag Saga xuất hiện trong Bảng 12-3.

Mô hình Phone Tag Saga thích hợp hơn cho các quy trình làm việc đơn giản không có nhiều điều kiện lỗi phổ biến. Mặc dù nó cung cấp một số đặc điểm tốt hơn so với Epic Saga, nhưng độ phức tạp do thiếu một bộ điều phối đã bù đắp cho nhiều lợi thế.

Fairy Tale Saga^(seo) Pattern

Câu chuyện cổ tích điển hình cung cấp những câu chuyện vui vẻ với cốt truyện dễ theo dõi, do đó có tên là Fairy Tale Saga, sử dụng giao tiếp đồng bộ, tính nhất quán cuối cùng và phối hợp, như được thể hiện trong Hình 12-8.

Figure 12-8. The Fairy Tale Saga^(seo) illustrates eventual consistency

Mô hình giao tiếp này làm giảm yêu cầu nguyên tử khó khăn, cung cấp nhiều tùy chọn hơn cho các kiến trúc sư để thiết kế hệ thống. Ví dụ, nếu một dịch vụ tạm thời không hoạt động, tính nhất quán cuối cùng cho phép lưu trữ một thay đổi cho đến khi dịch vụ được khôi phục. Cấu trúc giao tiếp cho Fairy Tale Saga được minh họa trong Hình 12-9.

Trong mô hình này, có một bộ điều phối để phối hợp yêu cầu, phản hồi và xử lý lỗi. Tuy nhiên, bộ điều phối không chịu trách nhiệm quản lý giao dịch, mà mỗi dịch vụ miền giữ trách nhiệm đó (để xem các ví dụ về quy trình làm việc thông dụng, hãy xem Chương 11). Do đó, bộ điều phối có thể quản lý các cuộc gọi bồi thường, nhưng không yêu cầu phải xảy ra trong một giao dịch đang hoạt động.

Figure 12-9. Isomorphic illustration of a Fairy Tale interaction

Đây là một mẫu mã hấp dẫn hơn nhiều và thường xuất hiện trong nhiều kiến trúc microservices. Có một trung gian giúp quản lý quy trình làm việc dễ hơn, giao tiếp đồng bộ là lựa chọn dễ hơn trong hai lựa chọn, và tính nhất quán cuối cùng loại bỏ thách thức phối hợp khó khăn nhất, đặc biệt là đối với xử lý lỗi.

Lợi thế hấp dẫn nhất của Fairy Tale Saga là sự thiếu vắng các giao dịch toàn diện. Mỗi dịch vụ miền quản lý hành vi giao dịch của riêng nó, dựa vào tính nhất quán cuối cùng cho quy trình làm việc tổng thể.

So với nhiều mẫu khác, mẫu này thường thể hiện sự cân bằng tốt về các sự đánh đổi.

Coupling level

Cuộc Saga Cổ Tích có tính gắn kết cao, với hai trong số ba yếu tố gắn kết được tối đa hóa trong mô hình này (giao tiếp đồng bộ và phối hợp có tổ chức). Tuy nhiên, yếu tố tồi tệ hơn về độ phức tạp của sự gắn kết—tính giao dịch—biến mất trong mô hình này để nhường chỗ cho tính nhất quán cuối cùng. Người điều phối phải vẫn quản lý các quy trình làm việc phức tạp, nhưng không bị ràng buộc bởi việc phải thực hiện trong một giao dịch.

Complexity level

Độ phức tạp của Fairy Tale Saga khá thấp; nó bao gồm các tùy chọn tiện lợi nhất (được tổ chức, đồng bộ hóa) với giới hạn lỏng lẻo nhất (tính nhất quán cuối cùng). Do đó, cái tên Fairy Tale Saga - một câu chuyện đơn giản với kết thúc hạnh phúc.

Responsiveness/availability

Khả năng phản hồi thường tốt hơn trong các phong cách giao tiếp như thế này vì, mặc dù các cuộc gọi là đồng bộ, người trung gian cần chứa ít trạng thái nhạy cảm với thời gian về các giao dịch đang diễn ra, cho phép cân bằng tải tốt hơn. Tuy nhiên, sự khác biệt thực sự trong hiệu suất đến từ tính không đồng bộ, được minh họa trong các mô hình tương lai.

Scale/elasticity

Việc thiếu sự kết nối thường dẫn đến khả năng mở rộng cao hơn; việc loại bỏ sự kết nối giao dịch cho phép mỗi dịch vụ mở rộng độc lập hơn.

Các đánh giá cho Fairy Tale Saga xuất hiện trong Bảng 12-4.