LỜI NÓI ĐẦU

Microservice là một cách tiếp cận đối với các hệ thống phân tán nhằm thúc đẩy việc sử dụng các dịch vụ chi tiết có vòng đời riêng của chúng, các dịch vụ này cộng tác với nhau. Bởi vì các microservice chủ yếu được mô hình hóa xung quanh các lĩnh vực kinh doanh, chúng tránh được các vấn đề của kiến trúc phân cấp truyền thống. Microservices cũng tích hợp các công nghệ và kỹ thuật mới đã xuất hiện trong thập kỷ qua, giúp họ tránh được sự sụp đổ của nhiều deploy kiến trúc hướng dịch vụ.

Cuốn sách này có đầy đủ các ví dụ cụ thể về việc sử dụng microservice trên khắp thế giới, bao gồm các tổ chức như Netflix, Amazon, Gilt và nhóm REA, những người đều nhận thấy rằng sự tự chủ ngày càng tăng mà kiến trúc này mang lại cho các nhóm trong công ty đó thuận lợi rất lớn.

Ai nên đọc cuốn sách này

Phạm vi của cuốn sách này rất rộng, vì hàm ý của các kiến trúc microservice chi tiết cũng rất rộng. Do đó, nó sẽ thu hút những người quan tâm đến các khía cạnh của thiết kế, phát triển, deploy, kiểm thử và bảo trì hệ thống. Những người trong số các bạn đã bắt đầu hành trình hướng tới các kiến trúc chi tiết hơn, cho dù là ứng dụng greenfield (một hệ thống hoàn toàn mới) hay là một phần của việc phân rã một hệ thống hiện có, kiểu giống monolithic, sẽ tìm thấy rất nhiều lời khuyên thiết thực để giúp bạn. Nó cũng sẽ giúp những người trong số các bạn muốn biết mọi rắc rối là gì, để bạn có thể xác định xem microservices có phù hợp với mình hay không.

Tại sao tôi viết cuốn sách này

Tôi bắt đầu nghĩ về chủ đề kiến trúc ứng dụng từ nhiều năm trước, khi làm việc để giúp mọi người cung cấp phần mềm của họ nhanh hơn. Tôi nhận ra rằng mặc dù các kỹ thuật tự động hóa, kiểm thử và Continuous Delivery trên cơ sở hạ tầng có thể hữu ích, nhưng nếu thiết kế tinh thần cơ bản của hệ thống không giúp bạn dễ dàng thực hiện các thay đổi, thì có những giới hạn đối với những gì có thể hoàn thành.

Đồng thời, nhiều tổ chức đang kiểm thử các kiến trúc lưu trữ chi tiết hơn để đạt được các mục tiêu tương tự, nhưng cũng để đạt được những thứ như cải thiện quy mô, tăng quyền tự chủ của các nhóm hoặc dễ dàng nắm bắt các công nghệ mới hơn. Kinh nghiệm của riêng tôi, cũng như của các đồng nghiệp của tôi tại ThoughtWorks và các nơi khác, buộc phải thực tế rằng việc sử dụng số lượng lớn các dịch vụ hơn với vòng đời độc lập của chúng dẫn đến nhiều vấn đề đau đầu hơn phải giải quyết. Theo nhiều cách, cuốn sách này được hình dung như một cửa hàng tổng hợp có thể giúp bao gồm nhiều loại tài liệu hàng đầu cần thiết để hiểu về microservices — điều gì đó đã giúp tôi rất nhiều trong quá khứ!

Một từ để nói về Microservices hôm nay

Microservices là một chủ đề nóng, mọi thứ đều thay đổi nhanh chóng. Mặc dù ý tưởng không phải là mới (ngay cả khi chính thuật ngữ microservice cũng đã xuất hiện rất lâu), nhưng kinh nghiệm của mọi người trên khắp thế giới, cùng với sự xuất hiện của các công nghệ mới, đang có ảnh hưởng sâu sắc đến cách chúng được sử dụng. Do tốc độ thay đổi nhanh chóng, tôi đã cố gắng tập trung cuốn sách này để nói về các ý tưởng hơn là các công nghệ cụ thể, biết rằng các chi tiết deploy luôn thay đổi nhanh hơn những suy nghĩ đằng sau chúng. Tuy nhiên, tôi hoàn toàn mong đợi rằng trong một vài năm nữa kể từ bây giờ, chúng ta sẽ học được nhiều hơn nữa về vị thế phù hợp của microservices và cách sử dụng tốt microservice.

Vì vậy, trong khi tôi đã cố gắng hết sức để chắt lọc ra những tinh túy nhất của chủ đề trong cuốn sách này, nếu chủ đề này khiến bạn hứng thú, hãy chuẩn bị cho nhiều năm học hỏi liên tục để luôn dẫn đầu về lĩnh vực nghệ thuật!

Đọc quyển sách này như nào

Cuốn sách này chủ yếu được sắp xếp theo định dạng dựa trên chủ đề. Do đó, bạn có thể muốn chuyển sang các chủ đề cụ thể mà bạn quan tâm nhất. Mặc dù tôi đã cố gắng hết sức để tham khảo các điều khoản và ý tưởng trong các chương trước, nhưng tôi muốn nghĩ rằng ngay cả những người tự cho mình là có kinh nghiệm cũng sẽ tìm thấy điều gì đó quan tâm trong tất cả các chương ở đây. Tôi chắc chắn khuyên bạn nên xem qua Chương 2, phần này đề cập một cách bao quát nhất chủ đề microservicecũng như cung cấp một số khung cho cách tôi tiếp cận mọi thứ trong trường hợp nếu bạn muốn đi sâu hơn vào một số chủ đề sau này.

Đối với những người mới làm quen với chủ đề này, tôi đã cấu trúc các chương theo cách mà tôi hy vọng sẽ có ý nghĩa khi đọc từ đầu đến cuối.

Dưới đây là tổng quan về những gì chúng tôi đề cập:

Chương 1, Microservice

Chúng ta sẽ bắt đầu bằng phần giới thiệu về microservices, bao gồm những lợi ích chính cũng như một số nhược điểm.

Chương 2, Sự tiến hoá của Kiến trúc phần mềm

Chương này thảo luận về những khó khăn mà chúng ta sẽ gặp phải và đánh đổi, cân nhắc với tư cách là kiến trúc sư của phần mềm và trình bày cụ thể về bao nhiêu điều chúng ta cần suy nghĩ với microservices.

Chương 3, Làm thế nào để Mô hình hóa Dịch vụ

Ở đây, chúng ta sẽ bắt đầu xác định ranh giới của microservices, sử dụng các kỹ thuật từthiết kế theo hướng nghiệp vụ để giúp tập trung suy nghĩ của chúng tôi.

Chương 4, Tích hợp

Đây là nơi chúng ta bắt đầu tìm hiểu sâu hơn một chút về các công nghệ cụ thể, khi chúng ta thảo luận về những loại kỹ thuật cộng tác dịch vụ nào sẽ giúp ích nhiều nhất cho chúng ta. Chúng tôi cũng sẽ đi sâu vào chủ đề giao diện người dùng và tích hợp với các sản phẩm thương mại (COTS) cũ và thương mại.

Chương 5, Tách phần mềm monolithic

Nhiều người quan tâm đến microservices như lời giải cho các hệ thống monolithic lớn, khó thay đổi và đây chính xác là những gì chúng tôi sẽ đề cập chi tiết trong phần này

Chương 6, Deploy

Mặc dù cuốn sách này chủ yếu là lý thuyết, nhưng một số chủ đề trong cuốn sách đã bị ảnh hưởng bởi những thay đổi gần đây trong công nghệ cũng như việc deploy, chúng ta sẽ khám phá những thứ liên quan đến vấn đề này ở đây

Chương 7, Thử nghiệm

Chương này đi sâu vào chủ đề kiểm thử, một lĩnh vực đặc biệt quan tâm khi xử lý việc deploy nhiều dịch vụ rời rạc. Đặc biệt lưu ý là vai trò của các hợp đồng do khách hàng định hướng có thể giúp chúng tôi đảm bảo chất lượng phần mềm của mình.

Chương 8, Giám sát

Kiểm tra phần mềm của chúng tôi trước khi đến môi trường production sẽ không hữu ích nếu sự cố xảy ra khi chúng tôi golive và chương này khám phá cách chúng tôi có thể giám sát các hệ thống chi tiết của mình và đáp ứng với một số sự phức tạp nổi bật của hệ thống phân tán.

Chương 9, Bảo mật

Ở đây, chúng tôi sẽ kiểm tra các khía cạnh bảo mật của microservices và xem xét cách xử lý xác thực và ủy quyền giữa người dùng với dịch vụ và giữa các dịch vụ. Bảo mật là một chủ đề rất quan trọng trong ngành khoa học máy tính, một chủ đề quá dễ bị xem nhẹ. Mặc dù tôi không phải là một chuyên gia bảo mật, nhưng tôi hy vọng rằng chương này ít nhất sẽ giúp bạn xem xét một số khía cạnh bạn cần lưu ý khi xây dựng hệ thống, và hệ thống microservice nói riêng.

Chương 10, Định luật Conway và Thiết kế Hệ thống

Chương này tập trung vào sự tác động lẫn nhau của cơ cấu tổ chức và kiến trúc. Nhiều tổ chức đã nhận ra rằng rắc rối sẽ xảy ra nếu bạn không giữ hai bên hòa hợp. Chúng tôi sẽ cố gắng giải quyết tận cùng tình thế khó xử này và xem xét một số cách khác nhau để điều chỉnh thiết kế hệ thống với cấu trúc của nhóm của bạn.

Chương 11, Microservice khi mở rộng

Đây là lúc chúng tôi bắt đầu xem xét việc thực hiện tất cả những điều này trên quy mô lớn, để chúng tôi có thể xử lý nguy cơ lỗi gia tăng có thể xảy ra với số lượng lớn dịch vụ cũng như lưu lượng truy cập lớn.

Chương 12, Kết hợp tất cả lại với nhau

Chương cuối cùng cố gắng chắt lọc bản chất cốt lõi của những gì làm cho các microservice trở nên khác biệt. Nó bao gồm một danh sách bảy nguyên tắc microservices, cũng như mộttóm tắt những điểm chính của cuốn sách.

Các quy ước được sử dụng trong cuốn sách này

Các quy ước về kiểu chữ sau đây được sử dụng trong cuốn sách này:

In nghiêng

Cho biết các thuật ngữ mới, URL, địa chỉ email, tên tệp và phần mở rộng tệp.

Độ rộng chữ không đổi

Được sử dụng cho danh sách chương trình, cũng như trong các đoạn văn để chỉ các phần của chương trình như tên biến hoặc hàm, cơ sở dữ liệu, kiểu dữ liệu, biến môi trường, câu lệnh và từ khóa.

Độ rộng chữ không đổi in đậm

Hiển thị các lệnh hoặc văn bản khác mà người dùng phải nhập theo nghĩa đen.

Độ rộng chữ không đổi in nghiêng

Hiển thị văn bản cần được thay thế bằng các giá trị do người dùng cung cấp hoặc bằng các giá trị được xác định theo ngữ cảnh.

Sự nhìn nhận

Cuốn sách này dành riêng cho Lindy Stephens, nếu không có cô ấy thì quyển sách này đã không hình thành. Cô ấy đã khuyến khích tôi bắt đầu cuộc hành trình này, hỗ trợ tôi trong suốt quá trình viết lách thường xuyên căng thẳng và là đối tác tốt nhất mà tôi có thể yêu cầu. Tôi cũng muốn dành điều này cho bố tôi, Howard Newman, người đã luôn ở bên tôi. Điều này là cho cả hai người.

Tôi muốn chọn ra Ben Christensen, Vivek Subramaniam và Martin Fowler vì đã đưa cho tôi những phản hồi chi tiết trong suốt quá trình viết, giúp định hình cuốn sách này. Tôi cũng muốn gửi lời cảm ơn đến James Lewis, người mà đã cùng tôi uống bia cùng thảo luận về những ý tưởng được trình bày trong cuốn sách này. Cuốn sách này sẽ chỉ là một cái bóng của chính nó nếu không có sự giúp đỡ và hướng dẫn của họ.

Ngoài ra, nhiều người khác đã giúp đỡ và phản hồi về các phiên bản đầu tiên của cuốn sách. Cụ thể, tôi muốn cảm ơn (không theo thứ tự cụ thể) Kane Venables, Anand Krishnaswamy, Kent McNeil, Charles Haynes, Chris Ford, Aidy Lewis, Will Thames, Jon Eaves, Rolf Russell, Badrinath Janakiraman, Daniel Bryant, Ian Robinson, Jim Webber, Stewart Gleadow, Evan Bottcher, Eric Sword, Olivia Leonard, và tất cả các đồng nghiệp khác của tôi tại ThoughtWorks và trong toàn ngành, những người đã giúp tôi đạt được điều này.

Cuối cùng, tôi muốn cảm ơn tất cả những người tại O’Reilly, bao gồm Mike Loukides vì đã đưa tôi vào hội đồng quản trị, biên tập viên Brian MacDonald, Rachel Monaghan, Kristen Brown, Betsy Waliszewski và tất cả những người khác đã giúp đỡ tôi theo cách có thể không bao giờ biết về.

CHƯƠNG 1 Microservices

Trong nhiều năm nay, chúng tôi đã và đang tìm ra những cách tốt hơn để xây dựng hệ thống. Chúng tôi đã học hỏi từ những gì đã có trước đó, áp dụng các công nghệ mới và quan sát cách một làn sóng công ty công nghệ mới hoạt động theo những cách khác nhau để tạo ra các hệ thống CNTT giúp làm cho cả khách hàng và nhà phát triển của chính họ hạnh phúc hơn.

Cuốn sách Domain-Driven Design (Addison-Wesley) của Eric Evans đã giúp chúng tôi hiểu tầm quan trọng của việc thể hiện thế giới thực trong mã nguồn của chúng tôi và chỉ cho chúng tôi những cách tốt hơn để lập mô hình hệ thống của chúng tôi. Khái niệm Continuous Delivery cho thấy cách chúng tôi có thể đưa phần mềm của mình lên môi trường production một cách ngày càng hiệu quả hơn, truyền cho chúng tôi ý tưởng rằng chúng tôi nên coi mọi thay đổi là một ứng cử viên release. Sự hiểu biết của chúng tôi về cách hoạt động của Web đã giúp chúng tôi phát triển những cách tốt hơn để máy giao tiếp với cácmáy. Khái niệm kiến trúc lục giác (hexagonal architecture) của Alistair Cockburn đã hướng dẫn chúng tôi thoát khỏi kiến trúc nhiều lớp nơi logic kinh doanh có thể ẩn giấu. Nền tảng ảo hóa cho phép chúng tôi cung cấp và thay đổi kích thước các server của mình theo ý muốn, với cơ sở hạ tầng tự động hóa cung cấp cho chúng tôi cách xử lý những máy này trên quy mô lớn. Một số tổ chức lớn, thành công như Amazon và Google tán thành quan điểm về các nhóm nhỏ sở hữu toàn bộ vòng đời dịch vụ của họ. Và, gần đây hơn, Netflix đã chia sẻ với chúng tôi các cách xây dựng hệ thống chống phân mảnh ở quy mô mà chỉ 10 năm trước khó có thể hiểu được.

Domain-driven. Continuous Delivery. Ảo hóa theo yêu cầu. Tự động việc deploy cơ sở hạ tầng. Các team nhỏtự trị. Hệ thống ở quy mô lớn. Microservices đã xuất hiện từ thế giới này. Chúng không được phát minh hoặc mô tả trước thực tế; chúng nổi lên như một xu hướng hoặc một kiểu mẫu, từ việc sử dụng trong thế giới thực. Nhưng chúng tồn tại chỉ vì tất cả những gì đã qua trước đó. Trong suốt cuốn sách này, tôi sẽ rút ra những điểm mấu chốt từ công việc trước đây để giúp vẽ nên bức tranh về cách xây dựng, quản lý và phát triển microservices.

Nhiều tổ chức đã phát hiện ra rằng bằng cách áp dụng một cách chi tiết kiến trúc microservice, họ có thể cung cấp phần mềm nhanh hơn và nắm bắt các công nghệ mới hơn. Microservicecho phép chúng ta tự do hơn đáng kể để phản ứng và đưa ra các quyết định khác nhau, cho phép chúng ta phản ứng nhanh hơn với sự thay đổi không thể tránh khỏi tác động đến tất cả chúng ta.

Microservices là gì?

Microservices là các dịch vụ nhỏ, tự trị hoạt động cùng nhau. Hãy làm rõ quan điểm đó xuống sâu một chút và xem xét các đặc điểm làm cho các microservice trở nên khác biệt.

Nhỏ và tập trung vào việc làm tốt một việc

Lượng mã nguồn tăng lên khi chúng tôi viết mã nguồn để thêm các tính năng mới. Theo thời gian, có thể khó biết nơi cần thực hiện thay đổi vì khối lượng mã nguồn quá lớn. Mặc dù có một định hướng cho các mã nguồn kiểumonolithic được chia mô-đun rõ ràng, nhưng tất cả các ranh giới trong quá trình tùy ý này thường bị chia nhỏ. Mã nguồnliên quan đến các chức năng tương tự nhau bắt đầu lan rộng khắp nơi, khiến việc sửa lỗi hoặc deploy khó khăn hơn.

Trong một hệ thống monolithic, chúng tôi chiến đấu chống lại những lực lượng này bằng cách cố gắng đảm bảo mã của chúng tôi gắn kết hơn, thường bằng cách tạo ra các mô-đun hoặc trừu tượng. Sự liên kết — động lực để có các mã liên quan được nhóm lại với nhau — là một khái niệm quan trọng khi chúng ta nghĩ về microservices. Điều này được củng cố bởi định nghĩa của Robert C. Martin về Nguyên tắc trách nhiệm duy nhất, trong đó nêu rõ "Tập hợp những thứ thay đổi vì cùng một lý do và tách những thứ thay đổi vì những lý do khác nhau."

Microservices áp dụng cách tiếp cận tương tự đối với các dịch vụ độc lập. Chúng tôi tập trung vào việc đặt ranh giới dịch vụ của mình vào ranh giới về nghiệp vụ, làm cho nó rõ ràng là nơi mã sống cho một phần chức năng nhất định. Và bằng cách giữ cho dịch vụ này tập trung vào một ranh giới rõ ràng, chúng tôi tránh xa những cám dỗ để nó tăng trưởng quá lớn, và tất cả những khó khăn liên quan mà điều này có thể gây ra.

Câu hỏi tôi thường được hỏi lànhỏ như thế nào là nhỏ_? Đưa ra một số dòng mã nguồn là cảmột vấn đề, vì một số ngôn ngữ dễbiểu đạt hơn những ngôn ngữ khác và do đó có thể làm được nhiều hơn với ít dòng mã hơn. Chúng ta cũng phải xem xét thực tế rằng chúng ta có nhiều dependenc, bản thân chúng chứa nhiều dòng mã. Ngoài ra, một số phần trong domain của bạn có thể phức tạp về mặt pháp lý, đòi hỏi nhiều mã nguồn hơn. Jon Eaves tại RealEstate.com.au ở Úc mô tả một microservice là thứ có thể được viết lại sau hai tuần, một quy tắc chung có ý nghĩa đối với bối cảnh cụ thể của anh ấy.

Một câu trả lời hơi sáo rỗng khác mà tôi có thể đưa ra làđủ nhỏ và không nhỏ hơn_. Khi phát biểu tại các hội nghị, tôi gần như luôn đặt câu hỏi rằngai có một hệ thống quá lớn và bạn muốn chia_nhỏ nó_? Gần như tất cả mọi người đều giơ tay. Chúng tôi dường như có cảm giác rất tốt về những gì là quá lớn và vì vậy có thể lập luận rằng một khi một đoạn mã không còncảm thấyquá lớn nữa, thì có lẽ nó đã đủ nhỏ.

Một yếu tố lớn trong việc giúp chúng tôi trả lờinhỏ như thế nào_? Làdịch vụ phù hợp với cấu trúc nhóm như thế nào. Nếu mã nguồn cơ sở quá lớn để được quản lý bởi một nhóm nhỏ, tìm cách chia nhỏ nó là rất hợp lý. Chúng ta sẽ nói thêm về việc sắp xếp tổ chức ở phần sau.

Khi nói đến việc nhỏ đến mức nào là đủ nhỏ, tôi muốn nghĩ theo các thuật ngữ sau: dịch vụ càng nhỏ, bạn càng tối đa hóa lợi ích và mặt trái của kiến trúc vi mô. Khi bạn có những service nhỏ hơn, những lợi ích xung quanh việc dependency lẫn nhau sẽ tăng lên. Nhưng một số phức tạp nổi lên từ việc ngày càng có nhiều bộ phận cùng phát triển, điều mà chúng ta sẽ khám phá trong suốt cuốn sách này. Khi bạn xử lý tốt hơn vớisự phức tạp này, bạn có thể cố gắng cho các dịch vụ nhỏ hơn và nhỏ hơn.

Tự chủ

Microservice của chúng tôi là một thực thể riêng biệt. Nó có thể được deploy như một dịch vụ biệt lập trên nền tảng như một dịch vụ (PAAS), hoặc nó có thể là quy trình hệ điều hành của riêng nó. Chúng tôi cố gắng tránh đóng gói nhiều dịch vụ vào cùng một máy, mặc dù định nghĩa vềmáytrong thế giới ngày nay khá mơ hồ! Như chúng ta sẽ thảo luận ở phần sau, mặc dù sự cô lập này có thể thêm một số chi phí, nhưng kết quả là sự đơn giản khiến hệ thống phân tán của chúng tôi dễ dàng lập luận hơn nhiều và các công nghệ mới hơn có thể giảm thiểu nhiều rủi ro liên quan đến hình thức deploy này.

Bản thân tất cả các giao tiếp giữa các dịch vụ đều thông qua các cuộc gọi mạng, để thực thi sự tách biệt giữa các dịch vụ và tránh các nguy cơ kết nối chặt chẽ.

Các dịch vụ này cần có khả năng thay đổi độc lập với nhau và được tự deploy mà không yêu cầu khách hàng thay đổi. Chúng tôi cần suy nghĩ về những gì dịch vụ của chúng tôi nên để lộ và những gì chúng nên cho phép được ẩn. Nếu có quá nhiều sự chia sẻ, các dịch vụ mà chúng tôi cung cấp sẽ lại trở nên liên kết chặt chẽ hơn với phần nội tại của dịch vụ. Điều này làm giảm quyền tự chủ của chúng tôi, vì nó đòi hỏi sự phối hợp bổ sung với người dùng khi thực hiện các thay đổi.

Dịch vụ của chúng tôi có giao diện lập trình ứng dụng (API) và các dịch vụ cộng tác giao tiếp với chúng tôi thông qua các API đó. Chúng tôi cũng cần phải suy nghĩ về thuật ngữ công nghệ nào phù hợp để đảm bảo rằng bản thân điều này không ảnh hưởng đến khách hàng. Điều này có thể có nghĩa là chọn các API không liên quan gì về công nghệ để đảm bảo rằng chúng tôi không bịhạn chế bởi các lựa chọn công nghệ. Chúng ta sẽ quay lại nhiều lần với tầm quan trọng của các API tốt, được tách biệt trong suốt cuốn sách này.

Nếu không tách rời, mọi thứ sẽ bị chia nhỏ đối với chúng tôi. Quy tắc vàng: bạn có thể thực hiện thay đổi đối với một dịch vụ và tự deploy dịch vụ đó mà không cần thay đổi bất kỳ điều gì khác không? Nếu câu trả lời là không, thì bạn sẽ khó đạt được nhiều lợi thế mà chúng ta thảo luận trong suốt cuốn sách này.

Để thực hiện tốt việc phân tách, bạn sẽ cần phải lập mô hình dịch vụ của mình phù hợp và nhận các API một cách đúng đắn. Tôi sẽ nói về điều đó rất nhiều.

Các lợi ích chính

Các lợi ích của microservices rất nhiều và đa dạng. Nhiều lợi ích trong số này có thể thấy ở bất kỳ hệ thống phân tán nào. Tuy nhiên, microservices có xu hướng đạt được những lợi ích này ở một mức độ lớn hơn chủ yếu là do chúng tiếp nhận các khái niệm đằng sau hệ thống phân tán và kiến trúc hướng dịch vụ đến đâu.

Tự do về công nghệ

Với một hệ thống bao gồm nhiều dịch vụ cộng tác với nhau, chúng tôi có thể quyết định sử dụng các công nghệ khác nhau bên trong mỗi dịch vụ. Điều này cho phép chúng tôi chọn công cụ phù hợp cho từng công việc, thay vì phải chọn cách tiếp cận tiêu chuẩn hóa hơn, một cách làm phù hợp với tất cả thường trở thành mẫu số chung thấp nhất.

Nếu một phần trong hệ thống của chúng tôi cần cải thiện hiệu suất của nó, chúng tôi có thể quyết định sử dụng một công nghệ khác có khả năng đạt được mức yêu cầu hiệu suất tốt hơn. Chúng tôi cũng có thể quyết định rằng cách chúng tôi lưu trữ dữ liệu của mình cần phải thay đổi đối với các phần khác nhau trong hệ thống của chúng tôi. Ví dụ: đối với mạng xã hội, chúng tôi có thể lưu trữ các tương tác của người dùng trong cơ sở dữ liệu hướng biểu đồ (GraphQL) để phản ánh bản chất có tính liên kết cao của biểu đồ xã hội, nhưng có lẽ các bài đăng mà người dùng thực hiện có thể được lưu trữ trong cơ sở dữ liệu kiểu tài liệu, tạo ra một kiến trúc không đồng nhất như thể hiện trong Hình 1-1.

Với microservices, chúng tôi cũng có thể áp dụng công nghệ nhanh hơn và hiểu rõ những tiến bộ mới có thể giúp chúng tôi như thế nào. Một trong những rào cản lớn nhất đối với việc thử và áp dụng công nghệ mới là những rủi ro đi kèm với nó. Với một ứng dụng monolithic, nếu tôi muốn thử một ngôn ngữ lập trình, cơ sở dữ liệu hoặc framework mới, thì bất kỳ thay đổi nào cũng sẽ ảnh hưởng đến một lượng lớn hệ thống của tôi. Với một hệ thống bao gồm nhiều dịch vụ, tôi có nhiều chỗ mới để thử một phần công nghệ mới. Tôi có thể chọn một dịch vụ có lẽ là rủi ro thấp nhất và sử dụng công nghệ ở đó, cầnbiết rằng tôi có thể hạn chế mọi tác động tiêu cực tiềm ẩn. Nhiều tổ chức nhận thấy khả năng tiếp thu nhanh hơn các công nghệ mới là một lợi thế thực sự của họ.

Tất nhiên, việc áp dụng nhiều công nghệ không phải là không có rủi ro hay chi phí. Một số tổ chức chọn đặt một số ràng buộc đối với lựa chọn ngôn ngữ. Netflix và Twitter, chẳng hạn, chủ yếu sử dụng Máy ảo Java (JVM) làm nền tảng, vì họ hiểu rất rõ về độ tin cậy và hiệu suất của hệ. Họ cũng phát triển các thư viện và công cụ cho JVM giúp hoạt động trên quy mô lớn dễ dàng hơn nhiều, nhưng lại gây khó khăn hơn cho các dịch vụ hoặc ứng dụng khách (client) không dựa trên Java. Nhưng cả Twitter và Netflix đều không chỉ sử dụng một stack công nghệ cho tất cả các công việc. Một điểm khác đối với những lo ngại về việc sử dụng các công nghệ khác nhau là khối lượng công việc, khối lượng mã nguồn. Nếu tôi thực sự có thể viết lại microservice của mình trong hai tuần, bạn có thể giảm thiểu rủi ro khi sử dụng công nghệ mới.

Như bạn sẽ thấy trong suốt cuốn sách này, cũng giống như nhiều điều liên quan đến microservices, đó là tất cả về việc tìm kiếm sự cân bằng phù hợp. Chúng ta sẽ thảo luận về cách lựa chọn công nghệ trong Chương 2, chương này tập trung vào việctiến hóakiến trúc; và trong Chương 4, liên quan đến tích hợp, bạn sẽ học cách đảm bảo rằng các dịch vụ của bạn có thể phát triển công nghệ của chúng một cách độc lập với nhau mà không có sự kết hợp quá mức.

Khả năng phục hồi

Một khái niệm quan trọng trong kỹ thuật phục hồi là vách ngăn (vách ngăn ở khoang tàu thuỷ). Nếu một thành phần của hệ thống bị lỗi, nhưng lỗi đó không rò rỉ và lan ra, bạn có thể cô lập sự cố và phần còn lại của hệ thống có thể tiếp tục hoạt động. Ranh giới dịch vụ trở thành vách ngăn rõ ràng của bạn. Trong một dịch vụ monolithic, nếu dịch vụ bị lỗi, mọi thứ sẽ ngừng hoạt động. Với một hệ thống monolithic, chúng ta có thể chạy trên nhiều máy để giảm nguy cơ hỏng hóc và đổ vỡ hệ thống, nhưng với microservices, chúng ta có thể xây dựng các hệ thống xử lý lỗi toàn bộ của các dịch vụ và làm suy giảm chức năng tương ứng.

Tuy nhiên, chúng tôi cần phải cẩn thận. Để đảm bảo các hệ thống microservice của chúng tôi có thể nắm bắt đúng cách khả năng phục hồi được cải thiện này, chúng tôi cần hiểu các nguồn lỗi mới mà các hệ thống phân tán phải đáp ứng. Hệ thống mạng có thể và sẽ thất bại, và máy móc cũng thế. Chúng tôi cần biết cách xử lý vấn đề này và tác động (nếu có) của nó đối với người dùng cuối đang sử dụng phần mềm của chúng tôi.

Chúng ta sẽ nói thêm về khả năng xử lý tốt hơn và cách xử lý các chế độ lỗi trong Chương 11.

Mở rộng quy mô

Với một dịch vụ lớn, monolithic, chúng tôi phải mở rộng mọi thứ cùng với nhau. Một phần nhỏ của hệ thống tổng thể của chúng tôi bị hạn chế về hiệu suất, nhưng nếu hành vi đó bị khóa trong một ứng dụng monolithic khổng lồ, chúng tôi phải xử lý việc mở rộng mọi thứ thay vì một phần nhỏ. Với các dịch vụ nhỏ hơn, chúng ta chỉ có thể mở rộng các dịch vụ cần mở rộng quy mô, cho phép chúng ta chạy các phần khác của hệ thống trên phần cứng nhỏ hơn, cầnít sức mạnh hơn, như trong Hình 1-2.

Gilt, một nhà bán lẻ thời trang trực tuyến, đã sử dụng microservices vì lý do chính xác này. Bắt đầu từ năm 2007 với một ứng dụng Rails kiểu monolithic, đến năm 2009 hệ thống của Gilt đã không thể đáp ứng với số lượng người dùng sử dụng nó. Bằng cách tách nhỏra các phần cốt lõi của hệ thống, Gilt chắc chắn có thể đáp ứng với lượng truy cập tăng đột biến và ngày nay có hơn 450 microservices, mỗi microservices chạy trên nhiều máy riêng biệt.

Khi sử dụng các hệ thống cung cấp theo yêu cầu như hệ thống được cung cấp bởi Amazon Web Services, chúng tôi thậm chí có thể áp dụng quy mô này theo yêu cầu cho những phần cần nó. Điều này cho phép chúng tôi kiểm soát chi phí của mình hiệu quả hơn. Không phải thường xuyên mà cách tiếp cận kiến trúc có thể tương quan chặt chẽ đến mức tiết kiệm chi phí gần như ngay lập tức.

Dễ deploy

Thay đổi một dòng mã nguồn đối với ứng dụng monolithic dài hàng triệu dòng yêu cầu toàn bộ ứng dụng phải được deploy để release thay đổi. Đó có thể là một lầndeploy có tác động lớn, rủi ro cao. Trong thực tế, việc deploy có tác động lớn, rủi ro cao sẽ không thường xuyên xảy ra do nỗi sợ hãi mà ai cũng có thể hiểu được. Thật không may, điều này có nghĩa là các thay đổi của chúng tôi được xây dựng và tích lũy giữa các bản release, cho đến khi phiên bản ứng dụng mới của chúng tôi bắt đầu được đưa lên môi trường production có hàng loạt thay đổi. Và sự khác nhau giữa các lần release càng lớn, thì nguy cơ chúng tôi gặp sự cố càng cao!

Với microservices, chúng ta có thể thực hiện thay đổi đối với một dịch vụ duy nhất và deploy nó một cách độc lập với phần còn lại của hệ thống. Điều này cho phép chúng tôi deploy mã nguồncủa mình nhanh hơn. Nếu sự cố xảy ra, nó có thể được cô lập nhanh chóng cho một dịch vụ riêng lẻ, giúp dễ dàng đạt được quá trình khôi phục nhanh. Điều đó cũng có nghĩa là chúng tôi có thể đưa chức năng mới của mình đến với những khách hàng nhanh hơn. Đây là một trong những lý do chính tại sao các tổ chức như Amazon và Netflix sử dụng các kiến trúc này — để đảm bảo họ loại bỏ nhiều trở ngại nhất có thể để đưa phần mềm ra thế giới thật.

Công nghệ trong lĩnh vực này đã thay đổi rất nhiều trong vài năm qua và chúng ta sẽ xem xét sâu hơn chủ đề deploy trong thế giới microservice trong Chương 6.

Liên kết với tổ chức

Nhiều người trong chúng tôi đã gặp phải các vấn đề liên quan đến các nhóm lớn vàmã nguồn cơ sở. Những vấn đề này có thể trở nên trầm trọng hơn khi nhóm bị phân tán. Chúng tôi cũng biết rằng các nhóm nhỏ hơn làm việc trên các mã nguồn cơ sở nhỏ hơn có xu hướng hiệu quả hơn.

Microservices cho phép chúng tôi điều chỉnh kiến trúc phù hợp hơn với tổ chức của mình, giúp chúng tôi giảm thiểu số lượng người làm việc trên bất kỳ mã nguồn cơ sở nào để đạt được điểm tốt về quy mô nhóm và năng suất. Chúng tôi cũng có thể chuyển quyền sở hữu dịch vụ giữa các nhóm để cố gắng giữ cho mọi người làm việc trên một dịch vụ được tập trung vào vị trí. Chúng ta sẽ đi vào chi tiết hơn về chủ đề này khi chúng ta thảo luận về định luật Conway trong Chương 10.

Khả năng kết hợp

Một trong những tiềm năng quan trọng của hệ thống phân tán và kiến trúc hướng dịch vụ là chúng tôi mở ra cơ hội tái sử dụng chức năng. Với microservices, chúng tôi cho phép sử dụng chức năng của mình theo những cách khác nhau cho các mục đích khác nhau. Điều này có thể đặc biệt quan trọng khi chúng ta nghĩ về cách khách hàng sử dụngphần mềm. Đã qua rồi cái thời mà chúng ta có thể suy nghĩ hạn hẹp về trang web trên máy tính để bàn hoặc ứng dụng di động của mình. Bây giờ chúng ta cần nghĩ đến vô số cách mà chúng ta có thể muốn kết hợp các khả năng với nhau cho Web, ứng dụng native, web di động, ứng dụng máy tính bảng hoặc cho thiết bị đeo. Khi các tổ chức chuyển từ suy nghĩ về các kênh hẹp sang các khái niệm toàn diện hơn về sự tương tác của khách hàng, chúng tôi cần các kiến trúc có thể theo kịp.

Với microservices, hãy nghĩ đến việc chúng tôi mở các đường nối trong hệ thống của mình mà các bên bên ngoài có thể giải quyết được. Khi hoàn cảnh thay đổi, chúng ta có thể xây dựng mọi thứ theo những cách khác nhau. Với ứng dụng monolithic, tôi thường có một đường may thô có thể được sử dụng từ bên ngoài. Nếu tôi muốn chia nhỏ điều đó để kiếm thứ gì đó hữu ích hơn, tôi sẽ cần một cái búa! Trong Chương 5, tôi sẽ thảo luận về các cách để bạn chia nhỏ các hệ thống monolithic hiện có và hy vọng thay đổi chúng thành một số microser có thể tái sử dụng và có thể kết hợp với nhau

Tối ưu hóa khả năng thay thế

Nếu bạn làm việc tại một tổ chức quy mô trung bình hoặc lớn hơn, rất có thể bạn biết đến một hệ thống mang tính di sản lớn và khó chịu nào đó đang nằm trong góc. Cái mà không ai muốn chạm vào. Điều quan trọng đối với cách công ty của bạn điều hành, nhưng điều đó tình cờ được viết trong một số biến thể Fortran kỳ lạ và chỉ chạy trên phần cứng đã hết tuổi thọ 25 nămtrước. Tại sao nó vẫn chưa được thay thế? Bạn biết lý do tại sao: đó là một công việc quá lớn và đầy rủi ro.

Với các dịch vụ riêng lẻ của chúng tôi có quy mô nhỏ, chi phí để thay thế chúng bằng cách deploy tốt hơn, hoặc thậm chí xóa chúng hoàn toàn, sẽ dễ quản lý hơn nhiều. Bạn có thường xuyên xóa hơn một trăm dòng mã chỉ trong một ngày và không lo lắng quá nhiều về điều đó? Với các microservice thường có kích thước tương tự, các rào cản đối với việc viết lại hoặc xóa hoàn toàn dịch vụ là rất thấp.

Các nhóm sử dụng phương pháp tiếp cận microservice cảm thấy thoải mái với các dịch vụ viết lại hoàn toàn khi được yêu cầu và chỉ giết dịch vụ khi không còn cần thiết nữa. Khi một mã nguồn cơ sở chỉ dài vài trăm dòng, rất khó để mọi người nảy sinh tình cảm gắn bó với nó và hơn nữa chi phí thay thế nó là khá nhỏ.

Còn về Kiến trúc Hướng Dịch vụ (SOA)?

Kiến trúc hướng dịch vụ (SOA) là một cách tiếp cận thiết kế trong đó nhiều dịch vụ hợp tác để cung cấp một số khả năng cuối cùng. Dịch vụ ở đây thường có nghĩa là một quy trình hoàn toàn riêng biệt chạy trong hệ điều hành. Giao tiếp giữa các dịch vụ này thường thông qua các cuộc gọi trên mạng chứ không phải là bằng cách gọi các phương thức trong một ranh giới quy trình (method call hoặc function call).

SOA nổi lên như một cách tiếp cận để loại bỏ những thách thức của những nền tảng monolithic lớn. Đó là một cách tiếp cận nhằm mục đích thúc đẩy khả năng tái sử dụng của phần mềm; Ví dụ: hai hoặc nhiều ứng dụng người dùng cuối đều có thể sử dụng các dịch vụ giống nhau. Nó nhằm mục đích giúp việc bảo trì hoặc viết lại phần mềm dễ dàng hơn, vì về mặt lý thuyết, chúng tôi có thể thay thế một phần mềm này bằng một phần mềm khác mà không ai biết, miễn là ngữ nghĩa của dịch vụ không thay đổi quá nhiều.

SOA và bản thân của nó là một ý tưởng rất hợp lý. Tuy nhiên, dù có nhiều nỗ lực nhưng vẫn chưa có sự đồng thuận caovề một cách làm SOA_tốt_. Theo quan điểm của tôi, phần lớn ngành công nghiệp phần mềm đã không thể nhìn nhận vấn đề một cách tổng thể và đưa ra một giải pháp thay thế hấp dẫn cho câu chuyện của các nhà cung cấp khác nhau trong lĩnh vực này.

Nhiều vấn đề đặt ra trước cửa SOA thực sự là các vấn đề với những thứ như giao thức truyền thông (ví dụ: SOAP), phần mềm trung gian của nhà cung cấp, thiếu hướng dẫn về mức độ chi tiết của dịch vụ hoặc hướng dẫn sai về việc chọn vị trí để phân chia hệ thống của bạn. Chúng tôi sẽ lần lượt giải quyết từng vấn đề này trong suốt phần còn lại của cuốn sách. Người hoài nghi có thể ám chỉ rằng các nhà cung cấp đã đồng ý (và trong một số trường hợp thúc đẩy) phong trào SOA như một cách để bán được nhiều sản phẩm hơn và những sản phẩm tự đặt tên đó cuối cùng đã làm suy yếu mục tiêu của SOA.

Phần lớn sự hiểu biết thông thường về SOA không giúp bạn hiểu được cách chia điều gì đó lớn thành điều gì đó nhỏ. Nó không nói về việc lớn như thế nào là quá lớn. Nó không nói đủ về những cách thực tế, thực tế để đảm bảo rằng các dịch vụ không trở nên quá khớp với nhau. Số lượng những điều không được giải đáp là nơi bắt nguồn của nhiều cạm bẫy liên quan đến SOA.

Phương pháp tiếp cận microservice đã xuất hiện từ việc sử dụng trong thế giới thực, giúp chúng ta hiểu rõ hơn về hệ thống và kiến trúc để thực hiện tốt SOA. Vì vậy, thay vì bạn nên nghĩ microservices như một cách tiếp cận cụ thể cho SOA giống như XP hoặc Scrum là những cách tiếp cận (framework) cụ thể để phát triển phần mềm theo phương pháp Agile.

Các kỹ thuật phân rã khác

Khi bạn nắm bắt được nó, nhiều lợi thế của một kiến trúc dựa trên microservice đến từ bản chất chi tiết của nó và thực tế là nó cung cấp cho bạn nhiều lựa chọn hơn về cách giải quyết vấn đề. Nhưng liệu các kỹ thuật phân tách tương tự có thể đạt được những lợi ích tương tự không?

Thư viện được chia sẻ

Một kỹ thuật phân tách rất chuẩn được tích hợp vào hầu như bất kỳ ngôn ngữ nào là chia nhỏ một mã nguồn cơ sở thành nhiều thư viện. Các thư viện này có thể được cung cấp bởi các bên thứ ba hoặc được tạo ra trong tổ chức của riêng bạn.

Thư viện cung cấp cho bạn một cách để chia sẻ chức năng giữa các nhóm và dịch vụ. Ví dụ, tôi có thể tạo một tập hợp các tiện ích thu thập hữu ích, hoặc có thể là một thư viện thống kê có thể được sử dụng lại.

Các nhóm có thể tự tổ chức xung quanh các thư viện này và bản thân các thư viện có thể được sử dụng lại. Nhưng có một số hạn chế.

Đầu tiên, bạn mất đi tính không đồng nhất của công nghệ thực sự. Thư viện thường phải sử dụng cùng một ngôn ngữ, hoặc ít nhất là chạy trên cùng một nền tảng. Thứ hai, sự dễ dàng mà bạn có thể mở rộng các phần của hệ thống của mình một cách độc lập với nhau bị hạn chế. Tiếp theo, trừ khi bạn đang sử dụng các thư viện được liên kết động, bạn không thể deploy một thư viện mới mà không deploy lại toàn bộ quy trình, do đó, khả năng deploy các thay đổi riêng biệt của bạn bị giảm. Và có lẽ nguyên nhân chính là bạn thiếu các liên kết rõ ràng xung quanh để xây dựng các biện pháp an toàn kiến trúc nhằm đảm bảo khả năng phục hồi của hệ thống.

Thư viện được chia sẻ vẫn có giá trị của nó. Bạn sẽ thấy mình đang tạo mã cho các nhiệm vụ phổ biến không dành riêng cho bất kì lĩnh vực nào của doanh nghiệp mà bạn muốn sử dụng lại trong toàn tổ chức, đây là một ứng cử viên rõ ràng để trở thành một thư viện có thể tái sử dụng. Tuy nhiên, bạn cần phải cẩn thận. Mã dùng chung được sử dụng để giao tiếp giữa các dịch vụ có thể trở thành điểm kết hợp (khiến mọi thứ kém linh hoạt), điều mà chúng ta sẽ thảo luận trong Chương 4.

Các dịch vụ có thể và nên sử dụng nhiều thư viện của bên thứ ba để tái sử dụng chung mã nguồn. Nhưng đókhông hẳn đã là giải pháp cho tất cả.

Mô-đun

Một số ngôn ngữ cung cấp các kỹ thuật phân rã mô-đun của riêng chúng vượt ra ngoài các thư viện đơn giản. Chúng cho phép một số quản lý vòng đời của các mô-đun, để chúng có thể được deploy thành một quy trình đang chạy, cho phép bạn thực hiện các thay đổi mà không cần gỡ bỏ toàn bộ quy trình.

Sáng kiến Cổng thông tin Nguồn mở (OSGI) đáng được gọi là một phương pháp tiếp cận công nghệ cụ thể để phân rã mô-đun. Bản thân Java không có khái niệm thực sự về mô-đun và chúng ta sẽ phải đợi ít nhất cho đến khi Java 9 thấy điều này được thêm vào ngôn ngữ. OSGI, nổi lên như một framework để cho phép cài đặt các trình cắm thêm (plugin) trong Eclipse Java IDE, hiện được sử dụng như một cách để trang bị thêm một khái niệm mô-đun trong Java thông qua một thư viện.

Vấn đề với OSGI là nó đang cố gắng thực thi những thứ như quản lý vòng đời mô-đun mà không có đủ sự hỗ trợ bằng chính ngôn ngữ đó. Điều này dẫn đến việc các tác giả mô-đun phải thực hiện nhiều công việc hơn để phân lập mô-đun thích hợp. Trong một ranh giới quy trình, họ cũng dễ rơi vào bế tắc khi làm cho các mô-đun kết hợp quá chặt chẽ với nhau, gây ra đủ loại vấn đề. Kinh nghiệm của bản thân tôi với OSGI, được đúc kết bởi các đồng nghiệp trong ngành, là ngay cả với những đội giỏi, OSGI vẫn dễ dàng trở thành một thứ phức tạp hơn nhiều so với những lợi ích của nó mang lại

Erlang theo một cách tiếp cận khác, trong đó các mô-đun được đưa vào ngôn ngữ ở runtime. Vì vậy, Erlang là một cách tiếp cận rất thuần thục để phân rã mô-đun. Các mô-đun Erlang có thể dừng, khởi động lại và nâng cấp mà không gặp vấn đề gì. Erlang thậm chí còn hỗ trợ chạy nhiều hơn một phiên bản của mô-đun tại một thời điểm nhất định, cho phép nâng cấp mô-đun một cách uyển chuyển hơn.

Khả năng của các mô-đun của Erlang thực sự rất ấn tượng, nhưng ngay cả khi chúng ta đủ may mắn để sử dụng một nền tảng khác có các khả năng này, vẫn có một điều gì đó thiếu sót giống như cách chúng ta làm với các thư viện được chia sẻ thông thường. Chúng tôi bị hạn chế nghiêm ngặt về khả năng sử dụng các công nghệ mới, bị hạn chế về cách chúng tôi có thể mở rộng quy mô một cách độc lập, có thể hướng tới các kỹ thuật tích hợp quá chặt chẽ và thiếu các liên kết dành cho các biện pháp an toàn kiến trúc.

Có một suy nghĩ cuối cùng rất đáng để chia sẻ. Về mặt kỹ thuật, có thể tạo ra các mô-đun độc lập, được kiểm chứng tốt trong một quy trình monolithic duy nhất. Và chúng ta hiếm khi thấy điều này xảy ra. Bản thân các mô-đun này sớm trở nên kết hợp chặt chẽ với phần còn lại của mã nguồn, và từ bỏ một trong những lợi ích chính của chúng. Một lần thực hiện việc chia nhỏ theo ranh giới của tiến trình sẽ vệ sinh sạch sẽ về mặt này (hoặc ít nhất là làm cho người ta khó có thể làm sai hơn!). Tất nhiên, tôi không gợi ý rằng đây phải là động lực chính cho việc phân tách quy trình, nhưng điều thú vị là những hứa hẹn về việc phân tách theo mô-đun trong ranh giới tiến trình hiếm khi được đưa ra trong thế giới thực.

Vì vậy, mặc dù việc phân rã mô-đun trong một ranh giới tiến trình có thể là điều bạn muốn làm cũng như phân rã hệ thống của bạn thành các dịch vụ, nhưng bản thân nó sẽ không thể giải quyết mọi thứ. Nếu bạn chỉ sử dụng Erlang, lợi ích việc sử dụng mô-đun của Erlang có thể giúp bạn đạt được một chặng đường rất dài, nhưng tôi nghi ngờ rằng nhiều người trong số bạn không thể làm điều đó. Đối với phần còn lại của chúng ta, chúng ta sẽ thấy các mô-đun cung cấp các loại lợi ích tương tự như các thư viện được chia sẻ.

Không có viên đạn bạc nào cả

Trước khi chúng ta kết thúc, tôi nên nói rằng microservices không phải là bữa trưa miễn phí hay viên đạn bạc, hay là một lựa chọn tồi như một chiếc búa vàng. Chúng có tất cả sự phức tạp liên quan của các hệ thống phân tán, và mặc dù chúng tôi đã học được rất nhiều về cách quản lý tốt các hệ thống bị phân tán (mà chúng tôi sẽ thảo luận trong suốt cuốn sách) thì vẫn còn nhiều khó khăn. Nếu bạn bảo lưu quan điểm hệ thống theo monolithic, bạn sẽ phải cải thiện nhiều hơn trong việc xử lý deploy, kiểm thử và giám sát để đạt được những lợi ích mà chúng tôi đã đề cập cho đến nay. Bạn cũng sẽ cần suy nghĩ khác về cách bạn mở rộng quy mô hệ thống của mình và đảm bảo rằng chúng có khả năng phục hồi. Cũng đừng ngạc nhiên nếu những thứ như giao dịch phân tán hoặc định lý CAP bắt đầu khiến bạn đau đầu!

Mọi công ty, tổ chức và hệ thống đều khác nhau. Một số yếu tố sẽ ảnh hưởng đến việc liệu microservices có phù hợp với bạn hay không và mức độ tích cực của bạn trong việc áp dụng chúng. Xuyên suốt mỗi chương của cuốn sách này, tôi sẽ cố gắng cung cấp cho bạn hướng dẫn làm nổi bật những cạm bẫy tiềm ẩn, những cạm bẫy này sẽ giúp bạn vạch ra một con đường ổn định.

Tóm tắt

Hy vọng rằng bây giờ bạn đã biết microservice là gì, điều gì làm cho nó khác với các kỹ thuật tổng hợp khác và một số ưu điểm chính là gì. Trong mỗi chương sau, chúng ta sẽ đi vào chi tiết hơn về cách đạt được những lợi ích này và cách tránh một số cạm bẫy phổ biến.

Có một số chủ đề cần đề cập, nhưng chúng ta cần bắt đầu từ đâu đó. Một trong những thách thức chính mà microservices đưa ra là sự thay đổi vai trò của những người thường dẫn dắt sự phát triển của hệ thống của chúng ta: các kiến trúc sư. Tiếp theo, chúng ta sẽ xem xét một số cách tiếp cận khác nhau đối với vai trò này có thể đảm bảo chúng ta tận dụng tối đa kiến trúc mới này.