Kiến trúc phần mềm và thiết kế hệ thống: Hướng dẫn về tài nguyên và hình ảnh lớn

Xin chào các đồng nghiệp.

Hôm nay chúng tôi cung cấp cho bạn bản dịch bài viết của Tugberk Ugurlu, người đã đảm nhận việc phác thảo trong một tập tương đối nhỏ các nguyên tắc thiết kế hệ thống phần mềm hiện đại. Đây là những gì tác giả nói về bản thân mình một cách tóm tắt:

Kiến trúc phần mềm và thiết kế hệ thống: Hướng dẫn về tài nguyên và hình ảnh lớn
Vì hoàn toàn không thể đề cập đến một chủ đề khổng lồ như các mẫu kiến ​​​​trúc + mẫu thiết kế trong một bài báo habro tính đến năm 2019, chúng tôi không chỉ đề xuất văn bản của chính ông Uruglu mà còn cả vô số liên kết mà ông đã vui lòng đưa vào đó. Nếu bạn thích nó, chúng tôi sẽ xuất bản một văn bản chuyên môn cao hơn về thiết kế hệ thống phân tán.

Kiến trúc phần mềm và thiết kế hệ thống: Hướng dẫn về tài nguyên và hình ảnh lớn

Hình ảnh Isaac Smith từ Bapt

Nếu bạn chưa bao giờ phải đối mặt với những thách thức như thiết kế một hệ thống phần mềm từ đầu, thì khi bắt đầu công việc đó, đôi khi bạn thậm chí còn không rõ nên bắt đầu từ đâu. Tôi tin rằng trước tiên bạn cần phải vạch ra các ranh giới để ít nhiều có ý tưởng tự tin về chính xác những gì bạn sẽ thiết kế, sau đó xắn tay áo lên và làm việc trong những ranh giới đó. Để bắt đầu, bạn có thể lấy một sản phẩm hoặc dịch vụ (lý tưởng nhất là sản phẩm hoặc dịch vụ mà bạn thực sự thích) và tìm ra cách triển khai nó. Bạn có thể ngạc nhiên về vẻ ngoài đơn giản của sản phẩm này và mức độ phức tạp thực sự của nó. Đừng quên: đơn giản - thường phức tạp, và điều đó không sao cả.

Tôi nghĩ lời khuyên tốt nhất tôi có thể đưa ra cho bất kỳ ai bắt đầu thiết kế một hệ thống là: đừng đưa ra bất kỳ giả định nào! Ngay từ đầu, bạn cần xác định rõ những thông tin thực tế đã biết về hệ thống này và những kỳ vọng liên quan đến nó. Dưới đây là một số câu hỏi hay để giúp bạn bắt đầu với thiết kế của mình:

  • Vấn đề chúng ta đang cố gắng giải quyết là gì?
  • Số lượng người dùng cao nhất sẽ tương tác với hệ thống của chúng tôi là bao nhiêu?
  • Chúng ta sẽ sử dụng những kiểu ghi và đọc dữ liệu nào?
  • Các trường hợp thất bại dự kiến ​​là gì, chúng ta sẽ xử lý chúng như thế nào?
  • Những kỳ vọng về tính nhất quán và tính sẵn sàng của hệ thống là gì?
  • Bạn có phải tính đến bất kỳ yêu cầu nào liên quan đến xác minh và quy định bên ngoài khi làm việc không?
  • Những loại dữ liệu nhạy cảm nào chúng ta sẽ lưu trữ?

Đây chỉ là một số câu hỏi hữu ích cho cả tôi và các nhóm mà tôi đã tham gia trong nhiều năm hoạt động chuyên môn. Nếu bạn biết câu trả lời cho những câu hỏi này (và bất kỳ câu hỏi nào khác có liên quan đến bối cảnh bạn phải làm việc), thì bạn có thể dần dần đi sâu vào chi tiết kỹ thuật của vấn đề.

Đặt mức ban đầu

Ý tôi là gì khi nói “đường cơ sở” ở đây? Trên thực tế, ở thời đại chúng ta, hầu hết các vấn đề trong ngành phần mềm đều “có thể” được giải quyết bằng các phương pháp và công nghệ hiện có. Theo đó, bằng cách điều hướng bối cảnh này, bạn sẽ có được một khởi đầu thuận lợi nhất định khi gặp phải những vấn đề mà người khác phải giải quyết trước bạn. Đừng quên rằng các chương trình được viết để giải quyết các vấn đề của doanh nghiệp và người dùng, vì vậy chúng tôi cố gắng giải quyết vấn đề theo cách đơn giản và dễ hiểu nhất (theo quan điểm của người dùng). Tại sao điều này quan trọng cần ghi nhớ? Có thể trong hệ tọa độ của mình, bạn muốn tìm kiếm các giải pháp duy nhất cho mọi vấn đề, bởi vì bạn nghĩ, “tôi là loại lập trình viên nào nếu tôi làm theo các mẫu ở mọi nơi”? Trong thực tế, nghệ thuật ở đây là đưa ra quyết định về việc phải làm gì và ở đâu. Tất nhiên, mỗi chúng ta đôi khi phải đối mặt với những vấn đề riêng, mỗi vấn đề đều là một thử thách thực sự. Tuy nhiên, nếu trình độ ban đầu của chúng ta được xác định rõ ràng, thì chúng ta biết nên dành năng lượng của mình vào việc gì: tìm kiếm các phương án có sẵn để giải quyết vấn đề đặt ra trước mắt hoặc nghiên cứu sâu hơn về nó và hiểu sâu hơn.

Tôi nghĩ rằng tôi đã có thể thuyết phục bạn rằng nếu một chuyên gia tự tin hiểu thành phần kiến ​​​​trúc của một số hệ thống phần mềm tuyệt vời là gì, thì kiến ​​​​thức này sẽ không thể thiếu để nắm vững nghệ thuật của một kiến ​​​​trúc sư và phát triển nền tảng vững chắc trong lĩnh vực này.

Được rồi, vậy bắt đầu từ đâu? bạn Donna Martina Có một kho lưu trữ trên GitHub có tên là hệ thống-thiết kế-mồi, từ đó bạn có thể học cách thiết kế các hệ thống quy mô lớn, cũng như chuẩn bị cho các cuộc phỏng vấn về chủ đề này. Kho lưu trữ có một phần với các ví dụ kiến trúc thực tế, đặc biệt, nó được xem xét cách họ tiếp cận thiết kế hệ thống của mình một số công ty nổi tiếngví dụ: Twitter, Uber, v.v.

Tuy nhiên, trước khi chuyển sang tài liệu này, chúng ta hãy xem xét kỹ hơn những thách thức kiến ​​trúc quan trọng nhất mà chúng ta gặp phải trong thực tế. Điều này rất quan trọng vì bạn phải xác định NHIỀU khía cạnh của một vấn đề cứng đầu và nhiều mặt, sau đó giải quyết nó trong khuôn khổ các quy định có hiệu lực trong một hệ thống nhất định. Jackson Gabbard, một cựu nhân viên của Facebook, đã viết Video dài 50 phút về phỏng vấn thiết kế hệ thống, nơi anh chia sẻ kinh nghiệm sàng lọc hàng trăm ứng viên của bản thân. Mặc dù video tập trung nhiều vào thiết kế hệ thống lớn và các tiêu chí thành công quan trọng khi tìm kiếm ứng viên cho vị trí như vậy nhưng video vẫn sẽ đóng vai trò là nguồn tài nguyên toàn diện về những điều quan trọng nhất khi thiết kế hệ thống. Tôi cũng đề nghị bản tóm tắt Video này.

Xây dựng kiến ​​thức về lưu trữ và truy xuất dữ liệu

Thông thường, quyết định của bạn về cách lưu trữ và truy xuất dữ liệu trong thời gian dài có tác động quan trọng đến hiệu suất hệ thống. Vì vậy, trước tiên bạn phải hiểu các đặc điểm ghi và đọc dự kiến ​​của hệ thống của mình. Sau đó, bạn cần có khả năng đánh giá các chỉ số này và đưa ra lựa chọn dựa trên các đánh giá đã thực hiện. Tuy nhiên, bạn chỉ có thể xử lý công việc này một cách hiệu quả nếu bạn hiểu được các kiểu lưu trữ dữ liệu hiện có. Về nguyên tắc, điều này hàm ý kiến ​​thức vững chắc liên quan đến lựa chọn cơ sở dữ liệu.

Cơ sở dữ liệu có thể được coi là cấu trúc dữ liệu có khả năng mở rộng và độ bền cao. Do đó, kiến ​​thức về cấu trúc dữ liệu sẽ rất hữu ích cho bạn khi chọn một cơ sở dữ liệu cụ thể. Ví dụ, Redis là một máy chủ cấu trúc dữ liệu hỗ trợ nhiều loại giá trị khác nhau. Nó cho phép bạn làm việc với các cấu trúc dữ liệu như danh sách và bộ cũng như đọc dữ liệu bằng các thuật toán nổi tiếng, chẳng hạn như LRU, tổ chức công việc đó theo một phong cách lâu bền và dễ tiếp cận.

Kiến trúc phần mềm và thiết kế hệ thống: Hướng dẫn về tài nguyên và hình ảnh lớn

Hình ảnh Samuel Zeller từ Bapt

Khi bạn đã hiểu đầy đủ về các kiểu lưu trữ dữ liệu khác nhau, hãy chuyển sang nghiên cứu tính nhất quán và tính sẵn có của dữ liệu. Trước hết bạn cần hiểu định lý CAP ít nhất là về mặt tổng quát, sau đó trau dồi kiến ​​thức này bằng cách xem xét kỹ hơn các mô hình đã được thiết lập Tính nhất quán и khả năng tiếp cận. Bằng cách này, bạn sẽ phát triển sự hiểu biết về lĩnh vực này và hiểu rằng việc đọc và ghi dữ liệu thực sự là hai vấn đề rất khác nhau, mỗi vấn đề đều có những thách thức riêng. Được trang bị một số mẫu nhất quán và sẵn có, bạn có thể tăng đáng kể hiệu suất hệ thống trong khi vẫn đảm bảo luồng dữ liệu trôi chảy đến các ứng dụng của mình.

Cuối cùng, kết thúc cuộc trò chuyện về vấn đề lưu trữ dữ liệu, chúng ta cũng nên đề cập đến bộ nhớ đệm. Nó có nên chạy đồng thời trên máy khách và máy chủ không? Dữ liệu nào sẽ có trong bộ đệm của bạn? Và tại sao? Bạn tổ chức việc vô hiệu hóa bộ đệm như thế nào? Nó sẽ được thực hiện thường xuyên, trong khoảng thời gian nhất định? Nếu có thì tần suất thế nào? Tôi khuyên bạn nên bắt đầu nghiên cứu những chủ đề này với phần tiếp theo mồi thiết kế hệ thống đã nói ở trên.

Mô hình giao tiếp

Hệ thống bao gồm nhiều thành phần khác nhau; đây có thể là các tiến trình khác nhau chạy trong cùng một nút vật lý hoặc các máy khác nhau chạy trên các phần khác nhau trong mạng của bạn. Một số tài nguyên trong mạng của bạn có thể ở chế độ riêng tư nhưng những tài nguyên khác phải ở chế độ công khai và mở cho người tiêu dùng truy cập chúng từ bên ngoài.

Cần đảm bảo sự liên lạc giữa các tài nguyên này với nhau, cũng như trao đổi thông tin giữa toàn bộ hệ thống và thế giới bên ngoài. Trong bối cảnh thiết kế hệ thống, ở đây một lần nữa chúng ta phải đối mặt với một loạt thách thức mới và độc đáo. Hãy xem chúng có thể hữu ích như thế nào luồng nhiệm vụ không đồng bộ, và cái gì pCó sẵn nhiều mô hình giao tiếp khác nhau.

Kiến trúc phần mềm và thiết kế hệ thống: Hướng dẫn về tài nguyên và hình ảnh lớn

Hình ảnh Tony Stoddard từ Bapt

Khi tổ chức giao tiếp với thế giới bên ngoài luôn rất quan trọng an toàn, việc cung cấp cũng cần được thực hiện nghiêm túc và tích cực theo đuổi.

Phân phối kết nối

Tôi không chắc rằng việc đưa chủ đề này vào một phần riêng biệt sẽ có vẻ hợp lý với mọi người. Tuy nhiên, tôi sẽ trình bày chi tiết khái niệm này ở đây và tôi tin rằng nội dung trong phần này được mô tả chính xác nhất bằng thuật ngữ “phân phối kết nối”.

Các hệ thống được hình thành bằng cách kết nối chính xác nhiều thành phần và giao tiếp của chúng với nhau thường được tổ chức trên cơ sở các giao thức đã được thiết lập, ví dụ: TCP và UDP. Tuy nhiên, những giao thức này thường không đủ để đáp ứng mọi nhu cầu của các hệ thống hiện đại, thường hoạt động với tải trọng cao và cũng phụ thuộc nhiều vào nhu cầu của người dùng. Thường cần phải tìm cách phân phối kết nối để đối phó với tải trọng cao như vậy trên hệ thống.

Sự phân phối này dựa trên sự nổi tiếng Hệ Thống Tên Miền (DNS). Hệ thống như vậy cho phép chuyển đổi tên miền chẳng hạn như phương pháp quay vòng có trọng số và dựa trên độ trễ để giúp phân phối tải.

Cân bằng tải về cơ bản là quan trọng và hầu như mọi hệ thống Internet lớn mà chúng ta xử lý ngày nay đều được đặt phía sau một hoặc nhiều bộ cân bằng tải. Cân bằng tải giúp phân phối yêu cầu của khách hàng trên nhiều phiên bản có sẵn. Cân bằng tải có cả phần cứng và phần mềm, tuy nhiên, trên thực tế, bạn thường phải xử lý phần mềm chẳng hạn. HAProxy и ELB. Proxy ngược về mặt khái niệm cũng rất giống với bộ cân bằng tải, mặc dù có một phạm vi giữa cái thứ nhất và cái thứ hai sự khác biệt rõ ràng. Những khác biệt này phải được tính đến khi thiết kế một hệ thống dựa trên nhu cầu của bạn.

Bạn cũng nên biết về mạng phân phối nội dung (CDN). CDN là mạng phân phối toàn cầu gồm các máy chủ proxy cung cấp thông tin từ các nút có vị trí địa lý gần hơn với một người dùng cụ thể. CDN được ưu tiên sử dụng hơn nếu bạn làm việc với các tệp tĩnh được viết bằng JavaScript, CSS và HTML. Ngoài ra, các dịch vụ đám mây cung cấp trình quản lý lưu lượng ngày nay rất phổ biến, chẳng hạn như Trình quản lý lưu lượng Azure, giúp bạn phân phối toàn cầu và giảm độ trễ khi làm việc với nội dung động. Tuy nhiên, những dịch vụ như vậy thường hữu ích trong trường hợp bạn phải làm việc với các dịch vụ web không trạng thái.

Hãy nói về logic kinh doanh. Cấu trúc logic nghiệp vụ, luồng nhiệm vụ và các thành phần

Vì vậy, chúng tôi đã cố gắng thảo luận về các khía cạnh cơ sở hạ tầng khác nhau của hệ thống. Rất có thể, người dùng thậm chí không nghĩ đến tất cả các yếu tố này trong hệ thống của bạn và thành thật mà nói, họ không quan tâm đến chúng chút nào. Người dùng quan tâm đến việc tương tác với hệ thống của bạn như thế nào, có thể đạt được điều gì khi thực hiện việc này cũng như cách hệ thống thực thi các lệnh của người dùng, hệ thống thực hiện những gì và như thế nào với dữ liệu người dùng.

Như tiêu đề của bài viết này gợi ý, tôi sẽ nói về kiến ​​trúc phần mềm và thiết kế hệ thống. Theo đó, tôi không có ý định đề cập đến các mẫu thiết kế phần mềm mô tả cách tạo ra các thành phần phần mềm. Tuy nhiên, càng nghĩ về nó, tôi càng thấy rằng ranh giới giữa các mẫu thiết kế phần mềm và các mẫu kiến ​​trúc rất mờ nhạt và hai khái niệm này có liên quan chặt chẽ với nhau. Hãy lấy ví dụ Đăng ký sự kiện (tìm nguồn cung ứng sự kiện). Khi bạn áp dụng mẫu kiến ​​trúc này, nó sẽ ảnh hưởng đến hầu hết mọi khía cạnh của hệ thống của bạn: lưu trữ dữ liệu lâu dài, mức độ nhất quán được áp dụng trong hệ thống của bạn, hình dạng của các thành phần trong đó, v.v., v.v. Vì vậy, tôi quyết định đề cập đến một số mẫu kiến ​​trúc liên quan trực tiếp đến logic nghiệp vụ. Mặc dù bài viết này sẽ phải giới hạn trong một danh sách đơn giản, nhưng tôi khuyến khích bạn làm quen với nó và suy nghĩ về những ý tưởng liên quan đến những mẫu này. Của bạn đây:

Phương pháp hợp tác

Rất khó có khả năng bạn sẽ thấy mình tham gia một dự án với tư cách là người tham gia chịu trách nhiệm hoàn toàn về quá trình thiết kế hệ thống. Ngược lại, rất có thể bạn sẽ phải tiếp xúc với những đồng nghiệp làm việc cả trong và ngoài nhiệm vụ của mình. Trong trường hợp này, bạn có thể cần cùng đồng nghiệp đánh giá các giải pháp công nghệ đã chọn, xác định nhu cầu kinh doanh và hiểu cách tốt nhất để song song hóa các nhiệm vụ.

Kiến trúc phần mềm và thiết kế hệ thống: Hướng dẫn về tài nguyên và hình ảnh lớn

Hình ảnh vạn hoa từ Bapt

Bước đầu tiên là phát triển sự hiểu biết chính xác và được chia sẻ về mục tiêu kinh doanh mà bạn đang cố gắng đạt được và những bộ phận chuyển động mà bạn sẽ phải giải quyết. Kỹ thuật lập mô hình nhóm, đặc biệt sự kiện gây bão (sự kiện gây bão) giúp đẩy nhanh đáng kể quá trình này và tăng cơ hội thành công của bạn. Công việc này có thể được thực hiện trước hoặc sau khi bạn phác thảo ranh giới dịch vụ của bạn, sau đó đào sâu hơn khi sản phẩm trưởng thành. Dựa trên mức độ nhất quán sẽ đạt được ở đây, bạn cũng có thể xây dựng ngôn ngữ thông dụng cho bối cảnh hạn chế mà bạn làm việc. Khi bạn cần nói về kiến ​​trúc hệ thống của mình, bạn có thể thấy nó hữu ích mô hình C4, đề xuất Simon Brown, nhất là khi bạn cần hiểu mình sẽ phải đi sâu vào chi tiết vấn đề, hình dung ra những điều bạn muốn truyền đạt.

Có lẽ có một công nghệ hoàn thiện khác về chủ đề này không kém phần hữu ích so với Thiết kế hướng tên miền. Tuy nhiên, bằng cách nào đó chúng ta quay lại tìm hiểu lĩnh vực chủ đề nên kiến ​​thức và kinh nghiệm trong lĩnh vực này Thiết kế hướng tên miền sẽ hữu ích cho bạn.

Nguồn: www.habr.com

Thêm một lời nhận xét