Giới thiệu Trong nền kinh tế hiện đại, việc tạo ra phần mềm là cả một ngành công nghiệp. Một mặt, nó giúp các doanh nghiệp tự động hóa và số hóa tất cả các quy trình, mặt khác, nó tạo ra lợi nhuận và tạo ra các tài sản ảo. Hiện nay, R&D đã trở nên phức tạp hơn, số lượng lập trình viên không ngừng tăng lên và các nhiệm vụ CNTT ngày càng phức tạp hơn. Những lý do này đã dẫn đến sự xuất hiện của các phương pháp luận và kiểu kiến trúc phát triển phần mềm mới. Các ứng dụng web hiện đại đa chức năng và sự chuyển đổi kỹ thuật số làm tăng các yêu cầu đối với phần mềm. Ứng dụng phải: có thể mở rộng dễ dàng, linh hoạt và đa nền tảng và có thể thay đổi cho các tác vụ của người dùng. Người quản lý tác vụ đặt ra các yêu cầu này ở giai đoạn phát triển phần mềm đó. Thứ nhất, để tạo ra phần mềm cho doanh nghiệp hiện đại, bạn phải nghiên cứu nghiêm túc quy trình phát triển phần mềm và lựa chọn kiến trúc phù hợp. Sự lựa chọn kiến trúc trong phát triển phần mềm Theo quy luật, trước đây tất cả các ứng dụng đều được phát triển dựa trên kiến trúc nguyên khối. Chúng ta hãy xem một ứng dụng nguyên khối là gì. Các ứng dụng nguyên khối được phát triển toàn bộ. Logic để xử lý các yêu cầu được đặt bên trong một quy trình duy nhất. Ứng dụng web nguyên khối có thể được cấu trúc dưới dạng mô-đun và khối. Các lớp, hàm, v.v. riêng biệt được sử dụng, tùy thuộc vào ngôn ngữ lập trình được sử dụng. Nhưng các kết nối giữa các mô-đun rất mạnh. Điều này dẫn đến kết luận sau: việc thay đổi bất kỳ mô-đun nào sẽ ảnh hưởng lớn đến hoạt động của toàn bộ ứng dụng. Ví dụ, chúng ta có thể xem xét một ứng dụng web điển hình cho LMS (hệ thống quản lý học tập). Phần mềm này có kiến trúc ba cấp, bao gồm: giao diện người dùng; thành phần phía máy chủ để truy cập dữ liệu và logic nghiệp vụ phần mềm; kho dữ liệu. Các chức năng kinh doanh của một ứng dụng như vậy rất khác nhau. Nó bao gồm các khối sau: "Khóa học và đào tạo", "Danh mục khóa học", "Cơ cấu tổ chức của công ty", "Lịch sự kiện", "Báo cáo", "Tin nhắn", "Tin tức", v.v. Tuy nhiên, tất cả chúng đều được kết hợp thành một khối nguyên khối duy nhất và nằm trên một máy chủ. Rất khó để mở rộng quy mô và thay đổi một ứng dụng như vậy. Hãy nêu ra những nhược điểm của kiến trúc nguyên khối: Ngay cả một thay đổi nhỏ trong ứng dụng web cũng dẫn đến việc lắp ráp và triển khai một phiên bản mới của toàn bộ phần mềm. Bạn chỉ có thể mở rộng quy mô toàn bộ ứng dụng. Không thể mở rộng quy mô một khối riêng biệt. Nếu bất kỳ mô-đun ứng dụng nào bị lỗi, thì kết quả là hoạt động của toàn bộ ứng dụng có thể bị gián đoạn. Các công cụ phát triển luôn bị giới hạn trong ngăn xếp công nghệ đã chọn. Không thuận tiện trong việc quản lý một nhóm lớn các nhà phát triển có trình độ. Mỗi nhà phát triển nên hiểu tất cả các chức năng của ứng dụng, không chỉ mô-đun của mình. Bất kỳ bản cập nhật nào cũng ảnh hưởng đến toàn bộ chức năng của phần mềm. Nó dẫn đến nguy cơ ứng dụng bị lỗi sau khi cập nhật. Do đó, chỉ những bản cập nhật hiếm hoi mới được thực hiện. Bất kỳ thay đổi nào trong cơ sở dữ liệu có thể ảnh hưởng đến hoạt động của toàn bộ ứng dụng và cần thay đổi mã. Nếu đây là một chương trình miễn phí nhỏ để dạy một số kỹ năng cá nhân cho người dùng bình thường và thậm chí hiếm khi được cập nhật, thì kiến trúc nguyên khối khá phù hợp cho sự phát triển như vậy. Nếu chúng ta đang nói về phần mềm của công ty (ví dụ, LMS) và thậm chí được cập nhật thường xuyên, thì cần phải chọn một kiến trúc microservice. là cách tiếp cận tối ưu để phát triển phần mềm. Trong kiến trúc microservice, ứng dụng web được chia thành các thành phần nhỏ và tự trị (microservices) với các giao diện cụ thể. Kiến trúc như vậy đã tìm thấy ứng dụng của nó trong lĩnh vực điện toán đám mây. Kiến trúc microservice Sự khác biệt giữa microservice và kiến trúc nguyên khối là gì? Trong kiến trúc microservice, ứng dụng web được phát triển như một tập hợp các thành phần nhỏ và kém liên kết với nhau, được gọi là microservices. Các dịch vụ vi mô được phát triển, triển khai và duy trì gần như độc lập với nhau. Ví dụ, một ứng dụng web cho LMS. Mỗi microservice chỉ nhằm giải quyết nhiệm vụ kinh doanh cụ thể của nó, có cơ sở dữ liệu và liên hệ với các microservice khác thông qua API. Do đó, cần phải phát triển các microservices sau cho ứng dụng web LMS: "Khóa học và đào tạo", "Danh mục khóa học", "Cơ cấu tổ chức của công ty", "Lịch sự kiện", "Báo cáo", "Tin nhắn", "Tin tức", v.v. Nhưng cần phải lưu ý rằng có một kiểu kiến trúc khác - kiến trúc hướng dịch vụ (SOA). Đôi khi nó bị nhầm lẫn với microservice. Có vẻ như sự khác biệt giữa kiến trúc microservice và SOA không quá rõ ràng. Nhưng có sự khác biệt giữa microservices và SOA. Điều này liên quan đến vai trò của xe buýt dịch vụ doanh nghiệp (ESB). SOA là một kiến trúc toàn công ty. Mục tiêu của nó là chuẩn hóa sự tương tác và tích hợp các dịch vụ web của công ty. Mục đích của kiến trúc microservice là phát triển một ứng dụng cụ thể. Các mẫu sau có liên quan đến SOA: CORBA, dịch vụ web, hàng đợi tin nhắn, ESB, v.v. Dưới đây chúng tôi sẽ nói chi tiết về những lợi thế của microservices để phát triển các ứng dụng web. Những ưu điểm chính của kiến trúc microservice Chúng tôi sẽ đánh giá những ưu điểm của microservices so với kiến trúc nguyên khối. Tính đơn giản và độc lập trong triển khai ứng dụng. Trong trường hợp microservices, bạn chỉ có thể triển khai một mô-đun ứng dụng. Ví dụ: trong trường hợp của chúng tôi với LMS, bạn chỉ có thể triển khai một mô-đun ("Lịch sự kiện"), giữ nguyên phần còn lại của các thành phần ứng dụng. Nếu bạn cần viết lại mã trong mô-đun "Báo cáo", thì không cần nhận nhiều quyền. Thành phần này ("Báo cáo") là một dịch vụ vi mô riêng biệt và độc lập. Khả năng mở rộng: độ chính xác và hiệu quả. Đầu tiên, cần xác định dịch vụ nhỏ nào sẽ yêu cầu khả năng mở rộng thường xuyên và dịch vụ nào sẽ không. Các mô-đun không cần phải thay đổi tỷ lệ thường xuyên, có thể được đặt trên các máy chủ yếu hơn và các mô-đun thường có khả năng mở rộng có thể được mở rộng một cách riêng biệt với tất cả các phần mềm khác. Tăng khả năng phục hồi ứng dụng. Thiết kế ứng dụng hợp lý và xây dựng các kết nối độc lập giữa các mô-đun mang lại lợi thế sau: lỗi của một trong các mô-đun không dẫn đến sự cố của toàn bộ phần mềm. Ví dụ: nếu mô-đun "Tin nhắn" bị lỗi, người dùng sẽ nhận được thông báo về việc tạm thời không sử dụng được khối này. Tất cả các khối ứng dụng khác sẽ hoạt động. Lựa chọn ngăn xếp công nghệ. Bằng cách phát triển từng microservice, bạn có thể chọn ngăn xếp công nghệ thích hợp nhất. Linh hoạt trong việc quản lý đội nhóm. Ví dụ: đội số 1 phát triển dịch vụ "Danh mục khóa học", đội số 2 - "Lịch sự kiện" và đội số 3 - "Tin tức". Đó là lý do tại sao một chuyên gia mới sẽ dễ dàng bắt tay vào công việc nhanh hơn. Không nhất thiết phải nghiên cứu chức năng của toàn bộ ứng dụng trong một thời gian dài, chỉ cần tìm hiểu tech stack cho một microservice cụ thể là đủ. Khả năng sử dụng lại các chức năng (cho các mục đích khác nhau và theo những cách khác nhau). Việc thay thế hoặc loại bỏ các dịch vụ không cần thiết được giải quyết một cách nhanh chóng và dễ dàng. Ví dụ: nếu một khách hàng cụ thể sẽ không sử dụng khối "Tin tức" trong LMS, thì mô-đun này có thể đơn giản bị loại bỏ mà không cần thay đổi toàn cục trong tất cả phần mềm. Mỗi microservice sử dụng cơ sở dữ liệu của nó. Thực tế này dẫn đến sự độc lập của các mô hình dữ liệu. Ví dụ, nếu một lập trình viên đã thay đổi mô hình dữ liệu trong một dịch vụ cụ thể, nó sẽ không ảnh hưởng đến hoạt động của các dịch vụ khác. Như chúng ta có thể thấy, kiến trúc microservice có những lợi thế đáng kể và ngày càng thu hút các nhà phát triển. Tuy nhiên, trước khi chọn một kiến trúc để phát triển phần mềm, cần xem xét những nhược điểm của microservices. Chúng tôi sẽ liệt kê những cái dưới đây. Nhược điểm của microservices Hệ thống microservices được phân phối. Một mặt, đây là một lợi thế trong công việc của phần mềm. Mặt khác, nếu có quá nhiều dịch vụ vi mô và mỗi dịch vụ trong số chúng thực hiện yêu cầu đến các dịch vụ khác, kết quả là thời gian phản hồi sẽ tăng lên và "điểm lỗi" sẽ xuất hiện. Có hai cách để giải quyết vấn đề này: thay đổi chi tiết cuộc gọi, có thể dẫn đến giảm số của họ; sự ra đời của tính không đồng bộ, các cuộc gọi được thực hiện song song, kết quả là, điều này dẫn đến thực tế là thời gian phản hồi cuối cùng là thời gian chậm nhất, chứ không phải tổng thời gian của tất cả các lần trì hoãn. Sự phức tạp liên tục của quá trình phát triển, dẫn đến tăng yêu cầu về trình độ của các lập trình viên. Trong kiến trúc microservice, vai trò của các quy trình tích hợp và quy trình phân phối liên tục là rất lớn. Và đó là lý do tại sao rất khó để xử lý rất nhiều quy trình mà không tự động hóa thử nghiệm và triển khai dịch vụ. Những yếu tố này đòi hỏi việc triển khai DevOps trong công ty và sự hợp tác chặt chẽ của các nhà phát triển với các kỹ sư hệ thống, người kiểm tra, hỗ trợ kỹ thuật, v.v. Phân cấp trong kiến trúc microservice tạo ra các vấn đề với tính nhất quán của microservice. Ví dụ: trong một ứng dụng nguyên khối, nhiều thay đổi có thể được thực hiện trong một giao dịch, nhưng cũng có thể quay trở lại nếu xảy ra lỗi, trong khi vẫn duy trì tính nhất quán của dữ liệu. Khi sử dụng microservices, có thể xảy ra tình huống sau: trong trường hợp một trong các dịch vụ bị trục trặc, microservice khác ngừng phản hồi. Trong trường hợp này, đó là vấn đề ưu tiên của nhà phát triển: bạn có thể ưu tiên tính sẵn có của các thành phần (trong trường hợp một dịch vụ bị lỗi, các dịch vụ khác sẽ tiếp tục hoạt động). Nói chung, các nhà phát triển phải tìm ra sự cân bằng giữa tính nhất quán của các dịch vụ và tính khả dụng của chúng, và điều này phải được thực hiện rất cẩn thận. Kết luận Trước khi chọn một kiến trúc microservice để phát triển các ứng dụng web, các nhà phát triển nên đánh giá cả ưu điểm và nhược điểm của nó. Rốt cuộc, việc lựa chọn sai kiến trúc có thể ảnh hưởng đến hiệu suất và chức năng của phần mềm trong tương lai. Nếu kiến trúc microservice được sử dụng không chính xác, các nhà phát triển có thể gặp các vấn đề lớn làm mất đi tất cả các lợi thế của microservice. Trong phần tiếp theo của bài viết, chúng ta sẽ xem xét các công cụ kỹ thuật mà một nhà phát triển sẽ sử dụng kiến trúc microservice trong phát triển phần mềm nên nắm vững.

Assembly

Read My Stories

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Making security fun one episode at a time

Kiến trúc Microservice trong phát triển ứng dụng: Ưu điểm và nhược điểm

dài quá đọc không nổi

Company Mentioned

Aleksey Alekseev

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

Kiến trúc Microservice trong phát triển ứng dụng: Ưu điểm và nhược điểm

dài quá đọc không nổi

Company Mentioned

Aleksey Alekseev

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN