Sự phát triển kiến ​​trúc dịch vụ

  。

1. Kỷ nguyên phân phối gốc

　　Trong một thời gian dài, tôi có thể có nhận thức giống như hầu hết mọi người, cho rằng nguồn gốc của kiến ​​trúc dịch vụ của chúng tôi là kiến ​​trúc nguyên khối. Trên thực tế, điều này không phải như vậy từ rất lâu trước khi hệ thống nguyên khối trở nên phổ biến, những người đi trước của chúng tôi đã khám phá điều này. việc sử dụng nhiều hệ thống độc lập làm việc cùng nhau để hoàn thành việc triển khai một hệ thống quy mô lớn.

　　Như tất cả chúng ta đều biết, máy tính lúc đầu là một thứ rất lớn và có lẽ nó chiếm cả một căn phòng để chứa hết thân hình khổng lồ của nó. Sau đó, vào cuối những năm 1970, máy tính cuối cùng đã được các nhà khoa học thông minh thiết kế và thiết kế lại, biến thành một chiếc máy vi tính có thể đặt trên bàn. Nhưng máy vi tính vào thời điểm này vẫn còn ở giai đoạn sơ khai. Nó không có khả năng tính toán tốc độ cao như chúng ta tưởng tượng. Nó thường chỉ có khả năng đánh địa chỉ 16 bit, tần số xung nhịp dưới 5 MHz và không gian bộ nhớ 128KB. Loại sức mạnh xử lý máy tính hạn chế này trực tiếp giới hạn quy mô của hệ thống có thể chạy trên một máy tính, điều này không có lợi cho chúng ta phát triển một hệ thống kinh doanh lý tưởng.

　　Để giải quyết vấn đề sức mạnh xử lý hạn chế của một máy tính, các nhà khoa học thông minh đã nghĩ ra một phương pháp phân chia và chinh phục rất hay. Nếu một máy tính không đủ, chúng ta sẽ chế tạo hai máy tính. Nếu hai máy tính không đủ, chúng ta sẽ làm. build 10. Những vấn đề lớn được chia thành những vấn đề nhỏ, tháo dỡ hệ thống lớn thành những hệ thống nhỏ và để chúng hợp tác với nhau, điều này không giải quyết được vấn đề sao? Ý tưởng này quả thực hay nhưng đáng tiếc là nó xuất hiện không đúng lúc. Tôi chỉ muốn nói điều này: Nếu chỉ một em bé không suy ra được công thức của Taylor thì sao bạn không tìm 10 em bé và yêu cầu họ thảo luận với nhau. nhau?

　　Những người đi trước chưa bao giờ chỉ nói đến mà còn thực sự làm được khi nói đến công nghệ phân tán, vì vậy những người IT Taishan Beidou thời kỳ đầu bắt đầu làm việc chăm chỉ. Chúng tôi đã làm việc cùng nhau để xây dựng một hệ thống công nghệ phân tán cho "Môi trường điện toán phân tán" (DCE), bao gồm một số thông số kỹ thuật gọi từ xa, hệ thống tệp phân tán, thông số xác thực dịch vụ, dịch vụ thời gian và dịch vụ thư mục rõ ràng, v.v., thậm chí còn quen thuộc nhất đối với chúng ta trong ngành CNTT ngày nay. Tuy nhiên, UUID cũng được phát minh ở DCE. Có thể nói DCE là người khởi xướng nền phân phối hiện đại.

　　Đương nhiên, các cuộc gọi từ xa là không thể thiếu cho sự phát triển phân tán. Tuy nhiên, xét đến trình độ phần cứng máy tính vào thời điểm đó, một khi thêm từ từ xa, thời gian thực hiện sẽ tăng theo cấp số nhân và hiệu quả sẽ giảm đi rất nhiều. Không có giải pháp hoàn hảo cho các vấn đề như gián đoạn dịch vụ, cô lập và hạ cấp. Như tôi đã đề cập, máy vi tính của chúng tôi lúc đầu giống như một đứa bé, nó quá yếu và quá yếu để hỗ trợ nó và các máy tính khác hoạt động tốt với nhau. . Về cách xây dựng một hệ thống phần mềm quy mô lớn, đó là cải thiện khả năng xử lý của một máy càng sớm càng tốt hoặc tìm giải pháp hoàn hảo hơn để xây dựng hệ thống phân tán.

　　Việc thăm dò chưa bao giờ dừng lại, nhưng thời đại phân phối ban đầu đã hát được vài năm nhưng cuối cùng vẫn không trở nên phổ biến.

  。

  。

  。

  。

2. Thời đại của một hệ thống duy nhất.

　　Kiến trúc nguyên khối có lẽ là kiến ​​trúc quen thuộc nhất với mọi người. Đây là kiến ​​trúc mà về cơ bản mọi nhà phát triển sẽ thực hành khi học. Nghĩ kỹ thì tôi chưa bao giờ xây dựng một kiến ​​trúc nguyên khối thuần túy kể từ khi bắt đầu làm việc về SOA. Trong hai năm qua, tôi đã sử dụng microservice. Tuy nhiên, bất kể toàn bộ hệ thống quy mô lớn, nếu chúng ta chỉ nhìn vào một dịch vụ nhất định trong kiến ​​trúc microservice, thì đây cũng có thể được gọi là phiên bản nâng cao của kiến ​​trúc nguyên khối. Nó chỉ có nhiều dịch vụ được đăng ký hơn và giả vờ gọi từ xa. thiết kế cấu trúc của gói phù hợp hơn với phong cách hiện tại và cách viết mã kinh doanh chính không khác nhiều so với cách viết của một hệ thống duy nhất. Tất nhiên, xét về tổng thể hệ thống, sự khác biệt thực sự lớn. Hệ thống nguyên khối đặt tất cả các chức năng mô-đun vào một dịch vụ này và mức độ ghép nối tương đối cao, trong khi các vi dịch vụ được tách ra và trách nhiệm của từng mô-đun. tương đối khác nhau. Rõ ràng là mỗi mô-đun là một dịch vụ riêng, điều này giải thích rõ ràng các khái niệm về khớp nối yếu và độ gắn kết cao.

　　Kể từ những năm 1980, Định luật Moore đã bắt đầu có hiệu lực đều đặn và hiệu suất của máy tính đã tăng với tốc độ đáng kinh ngạc là tăng gấp đôi cứ sau hai năm. Thông tin của chúng ta không phát triển bùng nổ như ngày nay, cũng như không có nhiều thông tin cao như hiện nay. Trong các kịch bản quy mô lớn với lưu lượng truy cập và tính đồng thời cao, một máy chủ hoặc một số ít máy chủ có thể hỗ trợ hoạt động của các hệ thống thông tin quy mô lớn, vì vậy thời đại của các hệ thống đơn lẻ đã trở thành xu hướng chủ đạo. trong 30 năm và được nhiều công ty nhỏ sử dụng ngày nay. Ngoài ra còn có nhiều hệ thống nhỏ sử dụng kiến ​​trúc nguyên khối.

　　Chính xác thì hệ thống nguyên khối là gì? Từ khái niệm tổng thể, không gì khác hơn là một người cũng có thể sống như một nhóm. Ví dụ: trong hệ thống thương mại điện tử của chúng ta ngày nay, mọi người đều có thể chọn phân chia mô-đun người dùng, mô-đun đặt hàng, mô-đun thanh toán, mô-đun sản phẩm, v.v. . vào các dịch vụ khác nhau Nó chạy ở giữa, mỗi dịch vụ thực hiện nhiệm vụ riêng của mình và có thể được bên kia gọi nếu nó hữu ích. Tuy nhiên, một hệ thống duy nhất sẽ không làm được điều này. có thể tự mình xử lý nhiều chức năng được đề cập ở trên. Chỉ cần cung cấp một dịch vụ là đủ và nó sẽ không bao giờ liên lạc với các dịch vụ khác để yêu cầu trợ giúp. Nếu có vấn đề với một trong các chức năng, tất cả chúng ta sẽ cùng nhau ngoại tuyến. Kiến trúc đơn lẻ cũng khá đẹp, như Kiến trúc MVC và sự kết hợp SSM mà chúng ta quen thuộc nhất thường được chia thành lớp trình bày Bộ điều khiển, lớp nghiệp vụ dịch vụ, lớp lưu giữ Mapper và lớp cơ sở dữ liệu DataBase. Chi phí khắc phục sự cố cũng như vận hành và bảo trì của nó thường nhỏ hơn nhiều so với các dịch vụ vi mô phổ biến hiện nay, ở đó chỉ có một dịch vụ duy nhất và nếu có sự cố thì rõ ràng đó là lỗi của nó.

　　Mặc dù kiến ​​trúc nguyên khối có những hạn chế riêng nhưng không thể phủ nhận rằng tất cả các kiến ​​trúc mới nổi của chúng ta đều phát triển dựa trên nền tảng của nó.

  。

  。

  。

  。

3. Thời đại SOA.

　　Về kiến ​​trúc SOA, thẳng thắn mà nói, đây là kiến ​​trúc mà tôi kém tự tin nhất khi giải thích rõ ràng, vì theo kinh nghiệm mấy năm qua, tôi luôn cảm thấy nó chưa có một định nghĩa mang tính hệ thống về mô hình kiến ​​trúc. nói rằng đó là một thực thể duy nhất, nhưng thực tế là đã có nhiều dịch vụ được phân phối. Có vẻ hơi vô nghĩa khi nói rằng chúng là các dịch vụ vi mô. Không có sự phân chia giữa chúng. Độ chi tiết nhỏ như vậy. Mặc dù các đồng nghiệp của tôi đã nói với tôi rằng chúng tôi đã sử dụng kiến ​​trúc SOA hai năm trước khi tôi bắt đầu làm việc, nhưng trên thực tế, tôi không có nhiều nhận thức về từ kiến ​​trúc vào thời điểm đó. Chỉ cần tôi có thể phát triển là đủ. và viết code Tiếp theo mình sẽ nói về một số hiểu biết không thành văn và hời hợt của mình. Mong các bạn thông cảm nếu sai sót và chỉ ra những góp ý của mình.

　　SOA thực sự là một kiến ​​trúc hướng dịch vụ. Nó có các quy tắc hướng dẫn rõ ràng về tính đóng gói, tính tự chủ, khả năng kết nối lỏng lẻo và khả năng sử dụng lại của các dịch vụ. Nó yêu cầu mỗi dịch vụ phải cụ thể và có hệ thống hơn. Nó không phải là một tập hợp các kiến ​​trúc như SOA. là một tập hợp các ý tưởng. Mỗi công ty có thể phát triển kiến ​​trúc hệ thống của riêng mình theo các kịch bản kinh doanh và hệ tư tưởng chỉ đạo của riêng mình. Ở đây tôi muốn nói về các phương pháp thiết kế của hai kiến ​​trúc. Bạn cũng có thể đánh giá xem chúng có thể được phân loại hay không. là phạm vi của kiến ​​trúc SOA.

　　Đầu tiên có lẽ là mẫu kiến ​​trúc mà tôi đã trải nghiệm từ 19 đến 21 năm. Công nghệ phát triển là SpringBoot + SpringData. JPA, bộ phận dịch vụ được chia đại khái thành ba dịch vụ: dịch vụ cơ bản, dịch vụ hệ thống kinh doanh và dịch vụ định thời gian có thể bao gồm các mô-đun chức năng cơ bản nhất của hệ thống: quyền, vai trò, người dùng, luồng phê duyệt, v.v. Mỗi mô-đun chức năng Sử dụng. phương pháp thầu phụ để phân biệt và ngành công nghiệp Các dịch vụ của hệ thống kinh doanh bao gồm nhiều chức năng kinh doanh khác nhau và có khá nhiều mô-đun chức năng để bảo mật, chúng tôi sẽ không đi sâu vào chi tiết ở đây. Khi đó, mỗi mô-đun chức năng cũng được phân biệt bằng cách xử lý các đường dẫn thời gian hợp đồng phụ; dịch vụ Tất cả các công việc cũng được thêm vào dịch vụ này để phát triển. Khi đó, toàn bộ dự án không có trung tâm đăng ký, không có cổng và không có trung tâm cấu hình. Các cuộc gọi giữa các dịch vụ được thực hiện thông qua url giả. Điều tuyệt vời hơn là nó còn trích dẫn Seata để quản lý giao dịch phân tán. DB riêng của nó, có thể nói hệ thống này thực sự là một hệ thống phân phối Nó là một hệ thống, nhưng nó vẫn không được phân loại là một microservice. Xét cho cùng, nhiều mô-đun kinh doanh không được chia riêng thành một dịch vụ. Nếu một mô-đun chức năng gặp sự cố, phần còn lại sẽ bị ảnh hưởng ở một mức độ nào đó, nhưng đúng là như vậy. đúng là nó thực sự là sự phát triển theo định hướng dịch vụ, vì vậy tôi nghĩ việc phân loại nó là SOA là hợp lý.

　　Loại thứ hai được đề cập trong một số video học tập mà tôi thường xem. Đó là kiến ​​trúc được phân chia theo chiều dọc tiêu chuẩn, được chia từ trên xuống dưới thành lớp ứng dụng, lớp dịch vụ nghiệp vụ, lớp nghiệp vụ cơ bản, lớp dịch vụ cơ bản và lớp lưu trữ. Lớp ứng dụng còn được gọi là lớp truy cập. Nó chỉ chịu trách nhiệm nhận yêu cầu từ người dùng và không truy cập trực tiếp vào DB. Nó xử lý dữ liệu bằng cách yêu cầu giao diện của các dịch vụ hạ nguồn. , chẳng hạn như các trang web tuyển dụng. Lớp nghiệp vụ cơ bản xử lý một số chức năng cốt lõi cơ bản nhất của hệ thống, chẳng hạn như các trang web tuyển dụng. Quản lý công việc và quản lý sơ yếu lý lịch của trang web có thể cung cấp một số hỗ trợ API cho lớp dịch vụ kinh doanh ngược dòng; lớp dịch vụ cơ bản là một số mô-đun độc lập với doanh nghiệp, được sử dụng để quản lý một số thông báo đẩy, phân tích tệp đính kèm và các tác vụ theo lịch trình. Nó có số lượng lớn yêu cầu, logic đơn giản và các chức năng độc lập; trong khi lớp lưu trữ giống như mysql, mongodb hoặc Es. Toàn bộ hệ thống sử dụng Dubbo và người quản lý vườn thú để hoàn thiện việc quản lý dịch vụ.

　　Trên thực tế, từ góc độ phân tách dịch vụ, so với loại thứ nhất, loại thứ hai chỉ tách lớp ứng dụng điều khiển thành một dịch vụ riêng biệt, các phương thức phân tách còn lại khá giống nhau. Từ góc độ kỹ thuật, cái đầu tiên không có trung tâm đăng ký, trong khi cái thứ hai sử dụng người quản lý vườn thú để làm trung tâm đăng ký. Có những điểm tương đồng và khác biệt giữa hai loại này, nhưng tóm lại, chúng đều theo hướng phân tách dịch vụ, đây thực sự là một sự thay đổi về chất so với kiến ​​trúc nguyên khối.

  。

  。

  。

  。

4. Kỷ nguyên của microservice.

　　Microservice có lẽ là một kiến ​​trúc dịch vụ hiện đang phổ biến. Nhiều người trước đây ủng hộ kiến ​​trúc SOA đang dần tiến gần hơn đến microservice. Về mặt khái niệm, microservice là sự kết hợp của nhiều dịch vụ nhỏ để xây dựng một phong cách kiến ​​trúc trong đó các dịch vụ này được xây dựng xoay quanh hoạt động kinh doanh. năng lực hơn là các tiêu chuẩn kỹ thuật cụ thể. Mỗi dịch vụ có thể sử dụng các ngôn ngữ lập trình khác nhau, công nghệ lưu trữ dữ liệu khác nhau và chạy trong các quy trình khác nhau. Các dịch vụ này áp dụng các cơ chế giao tiếp nhẹ và cơ chế triển khai tự động để đạt được khả năng giao tiếp, vận hành và bảo trì.

　　Cuốn sách “Kiến trúc Phoenix” đã đề cập rằng microservice có 9 đặc điểm kinh doanh và kỹ thuật cốt lõi, đó là: xây dựng xung quanh năng lực kinh doanh, quản trị phi tập trung, hiện thực hóa các thành phần độc lập và tự chủ thông qua dịch vụ, tư duy hướng đến sản phẩm, phân cấp dữ liệu, thiết bị đầu cuối mạnh bao gồm đường ống, lỗi -Thiết kế khoan dung, thiết kế tiến hóa và tự động hóa cơ sở hạ tầng. Theo thuật ngữ thông thường, điều đó có nghĩa là chúng tôi phân chia các dịch vụ ở cấp độ chi tiết dựa trên các tình huống kinh doanh. Mỗi vi dịch vụ tạo thành hệ thống riêng có thể chạy độc lập và có thể được quản lý bởi những người khác nhau. chúng ta phải tính đến khả năng mở rộng và hiệu suất chịu lỗi. Do hệ thống được chia thành nhiều vi dịch vụ nên việc xây dựng tự động phải được hoàn thành trong quá trình triển khai để giảm bớt các hoạt động không cần thiết của con người nhằm tránh thời gian chờ đợi lâu hoặc lỗi vận hành.

　　Về việc triển khai kỹ thuật của hệ thống microservice, chúng tôi thường sử dụng các thành phần springcloud thế hệ đầu tiên hoặc sử dụng các thành phần khác nhau của Springcloud alibaba thế hệ thứ hai. Các thành phần springcloud thế hệ đầu tiên phổ biến hơn là: trung tâm đăng ký dịch vụ eureka, cân bằng tải ribbon, hystrix. cầu chì, thành phần gọi từ xa giả, cổng zuul, trung tâm cấu hình phân tán cấu hình đám mây mùa xuân, thành phần trình điều khiển tin nhắn luồng đám mây mùa xuân. Những cái phổ biến hơn ở thế hệ thứ hai là trung tâm cấu hình và đăng ký dịch vụ nacos, thành phần cổng, bộ ngắt mạch điều khiển luồng Sentinel và thành phần xuống cấp, và thành phần quản lý giao dịch phân tán Seata. Tất nhiên, việc sử dụng cả hai không cần phải phân chia rõ ràng như vậy. Nếu tôi sử dụng thế hệ thứ nhất thay vì thế hệ thứ hai thì không cần phải chồng chất tất cả các thành phần chỉ để chứng minh. rằng tôi có microservices. Đối với phần trên, đây vẫn là bản phân tích chi tiết về các tình huống cụ thể. Giống như công việc thông thường của tôi, trung tâm đăng ký có thể sử dụng eureka, nhưng trung tâm cấu hình sử dụng nacos, cổng sử dụng GateWay và cuộc gọi từ xa. sử dụng giả vờ.

　　Các dịch vụ vi mô thực sự theo đuổi một phong cách kiến ​​trúc tự do hơn. Nó loại bỏ các ràng buộc cứng nhắc trong SOA và sử dụng thực tiễn làm tiêu chuẩn thay vì các ràng buộc quy chuẩn. Nhưng điều tôi muốn nói ở đây là không phải hệ thống nào cũng phù hợp với microservice, và thực sự không cần thiết phải tiến gần hơn đến microservice mà không cần suy nghĩ. Nếu một hệ thống có thể được xử lý một cách đơn giản thì không cần phải tốn kém. tiền bạc và nhân lực để chia nhỏ ra. Tạo ra nhiều dịch vụ nhỏ để thể hiện ý nghĩa kỹ thuật của bạn. Đường liên kết cuộc gọi càng ngắn thì hiệu quả càng cao và càng ít xảy ra lỗi. Tôi có sự hiểu biết sâu sắc ở đây, trên thực tế, khi chúng tôi tham gia vào SOA hai năm trước, hai bộ mã duy nhất mà công ty thực sự thường xuyên thay đổi là dịch vụ kinh doanh và dịch vụ cơ bản, vì vậy mỗi khi xảy ra sự cố, nó có thể được xử lý nhanh chóng. Hiện tại, microservice này đã được định vị và giải quyết, có hàng tá microservice trong toàn bộ hệ thống lớn và nhiều dịch vụ được cung cấp bởi các đồng nghiệp khác. Tôi không quen với việc quản lý, nhưng tôi thường phải gọi API do họ cung cấp. Mỗi khi có sự cố xảy ra, tôi có thể phải mời vài đồng nghiệp cùng thảo luận. Độ khó của việc giải quyết vấn đề càng tăng lên và khi lên mạng thì rất nhiều. các dịch vụ cần phải được sắp xếp theo thứ tự và thứ tự, tôi sợ rằng một số dịch vụ sẽ quên truy cập trực tuyến và gây ra sự cố. Lý do nhiều công ty cần sử dụng microservice là vì hệ thống kinh doanh của họ ngày càng phức tạp, lưu lượng truy cập ngày càng tăng và thông tin dữ liệu trở nên khổng lồ nên họ phải sử dụng microservice để xử lý. Tuy nhiên, hệ thống của bạn sẽ đơn độc. trong tương lai rõ ràng là sẽ không có cảnh phức tạp nào được thêm vào, vì vậy tôi khuyên bạn nên giữ nguyên ý định ban đầu của mình.

  。

  。

  。

5. Thời kỳ hậu vi dịch vụ.

　　Thời đại của microservice có thể nói là thời đại do Spring Cloud thống trị. Đối với việc khám phá đăng ký, quản lý theo dõi, cân bằng tải và giao tiếp truyền tải xuất hiện trong kiến ​​trúc phân tán, chúng ta luôn có thể tìm thấy giải pháp trong các thành phần do Spring Cloud cung cấp, nhưng. các giải pháp này đều được cung cấp dưới dạng phần mềm. Hãy thử nghĩ xem, liệu chúng ta có thể không bị giới hạn ở phần mềm và xem xét các giải pháp phần cứng không?

　　Trên thực tế, Kubernetes cung cấp một bộ giải pháp cấp cơ sở hạ tầng. Sau đây sẽ cho thấy sự so sánh với giải pháp springcloud thế hệ đầu tiên truyền thống:

。	Kubernetes .	Mây mùa xuân 。
Mở rộng linh hoạt.	Tự động điều chỉnh tỷ lệ.	。
Khám phá dịch vụ.	KubeDNS/CoreDNS 。	Đám mây mùa xuân Eureka 。
Trung tâm cấu hình.	ConfigMap/Bí mật 。	Cấu hình Spring Cloud.
Cổng dịch vụ.	Bộ điều khiển Ingress.	Đám mây mùa xuân Zuul 。
Cân bằng tải.	Bộ cân bằng tải 。	Dải băng mây mùa xuân.
Dịch vụ được an toàn.	Giao diện lập trình ứng dụng RBAC.	Bảo mật đám mây mùa xuân.
Theo dõi và giám sát.	API/Bảng điều khiển số liệu.	Tua bin đám mây mùa xuân.
Hạ cấp bộ ngắt mạch.	。	Đám mây mùa xuân Hystrix 。

  。

　　Toàn bộ bộ giải pháp Kubernetes được hưởng lợi từ sự phát triển của công nghệ ảo hóa và công nghệ container hóa trong nhiều năm qua. Khi cơ sở hạ tầng ảo hóa mở rộng từ một vùng chứa dịch vụ duy nhất sang một cụm dịch vụ, mạng truyền thông và cơ sở lưu trữ bao gồm nhiều vùng chứa, phần mềm và phần cứng. bị mờ. Khi phần cứng ảo hóa có thể theo kịp tính linh hoạt của phần mềm, các vấn đề kỹ thuật không liên quan đến doanh nghiệp có thể được giải quyết từ cấp độ phần mềm và lặng lẽ trong cơ sở hạ tầng phần cứng, cho phép phần mềm chỉ tập trung vào doanh nghiệp và thực sự tập trung vào khả năng kinh doanh để xây dựng đội ngũ xung quanh sản phẩm.

　　Sự xuất hiện của Kubernetes trong quá trình phát triển hệ sinh thái container đánh dấu sự xuất hiện của thời kỳ hậu vi dịch vụ, nhưng nó vẫn có những nhược điểm riêng. Đặc thù của nhiều tình huống có thể dễ dàng giải quyết thông qua phần mềm, nhưng ở cấp độ phần cứng, nó lại là mục tiêu. tại Việc quản lý toàn bộ vùng chứa tương đối thô và thường khó đạt được sự kiểm soát hiệu quả. Tuy nhiên, chúng ta vẫn có thể tin rằng với sự cải tiến và phát triển liên tục của Kubernetes, nó sẽ trở thành môi trường vận hành tiêu chuẩn của máy chủ. và nó sẽ dần dần có thể thay thế Mùa Xuân hôm nay Đối với chức năng của hầu hết các thành phần trong Cloud Family Bucket, các vi dịch vụ chỉ cần xem xét logic nghiệp vụ của riêng chúng. Đây sẽ là giải pháp tối ưu cho thiết bị đầu cuối thông minh.

  。

6. Thời đại vô dụng.

　　Khi nói về thời đại không có dịch vụ, chúng ta phải nhắc đến một từ quen thuộc trong ngành - điện toán đám mây. Bách khoa toàn thư Baidu giới thiệu điện toán đám mây như thế này: Điện toán đám mây là một loại điện toán phân tán, đề cập đến việc phân tách các chương trình xử lý điện toán dữ liệu khổng lồ thành vô số chương trình nhỏ thông qua mạng "đám mây", sau đó thông qua nhiều chương trình nhỏ Một hệ thống bao gồm. các máy chủ nội bộ xử lý và phân tích các chương trình nhỏ này để thu được kết quả và trả về cho người dùng. Trong những ngày đầu của điện toán đám mây, nói một cách đơn giản, đó là tính toán phân tán đơn giản, giải quyết việc phân bổ nhiệm vụ và hợp nhất các kết quả tính toán. Vì vậy, điện toán đám mây còn được gọi là điện toán lưới. Thông qua công nghệ này, hàng chục nghìn dữ liệu có thể được xử lý trong thời gian rất ngắn (vài giây), từ đó đạt được các dịch vụ mạng mạnh mẽ. Dịch vụ đám mây được đề cập ở giai đoạn này không còn chỉ là một loại điện toán phân tán mà là kết quả của sự phát triển và nhảy vọt hỗn hợp của các công nghệ máy tính như điện toán phân tán, điện toán tiện ích, cân bằng tải, điện toán song song, lưu trữ mạng, dự phòng nóng và ảo hóa. Điện toán đám mây là hệ thống có sức mạnh tính toán cực kỳ mạnh được hình thành thông qua mạng máy tính (chủ yếu là Internet), có thể lưu trữ, thu thập các tài nguyên liên quan và cấu hình chúng theo yêu cầu để cung cấp cho người dùng các dịch vụ được cá nhân hóa.

　　Một số chuyên gia dự đoán rằng serverless sẽ trở thành hình thức điện toán đám mây chính trong tương lai. Vì điện toán đám mây chứa đầy đủ nhiều thiết kế kiến ​​trúc phức tạp và việc xử lý khó khăn trên các máy chủ đám mây nên các nhà phát triển không cần phải xem xét các thành phần kỹ thuật nào cả, vì các thành phần này đã được tạo sẵn nên không cần phải xem xét việc triển khai nó được lưu trữ trên đám mây; không cần phải quan tâm đến sức mạnh tính toán, nó được hỗ trợ bởi toàn bộ trung tâm dữ liệu; không cần phải quan tâm đến việc vận hành và bảo trì, đã có nhà cung cấp dịch vụ điện toán đám mây giúp bạn. Các nhà phát triển chúng tôi chỉ cần tập trung hoàn toàn vào kinh doanh.

　　Dù là kiến ​​trúc SOA hay kiến ​​trúc microservice, so với kiến ​​trúc nguyên khối ban đầu, kiến ​​trúc dường như ngày càng trở nên phức tạp hơn và yêu cầu kỹ thuật đối với các nhà phát triển cũng đặc biệt cao. Không có dịch vụ, nó đang phát triển theo hướng đơn giản và phức tạp. các phần của dịch vụ được lưu trữ trên đám mây. Nếu nó trở nên phổ biến trong tương lai, điều cần thiết có thể là các nhà phát triển có kỹ năng kinh doanh mạnh mẽ, thay vì các chuyên gia kỹ thuật thuần túy chỉ bao gồm hai phần: cơ sở phụ trợ (Backend) và Chức năng.

   Các cơ sở phụ trợ đề cập đến cơ sở dữ liệu, hàng đợi tin nhắn, nhật ký, lưu trữ, v.v., là các thành phần kỹ thuật được sử dụng để hỗ trợ hoạt động logic nghiệp vụ nhưng không có ý nghĩa kinh doanh. Các cơ sở phụ trợ này đều chạy trên đám mây và được cung cấp. được gọi là không có máy chủ. Đó là "Phần cuối như một dịch vụ (BaaS)".

   Hàm đề cập đến mã logic nghiệp vụ. Khái niệm và mức độ chi tiết của hàm ở đây rất gần với hàm từ góc độ mã hóa chương trình. Sự khác biệt là hàm trong serverless chạy trên đám mây và không cần phải xem xét tính toán. các vấn đề về điện hoặc lập kế hoạch năng lực (từ Bạn không cần phải xem xét từ quan điểm kỹ thuật, nhưng bạn vẫn phải cân nhắc xem ví của mình có đủ theo quan điểm thanh toán hay không, nó được gọi là "Chức năng như một Dịch vụ"). " (FaaS).

　　Thành thật mà nói, tôi không thể mô tả chi tiết nó sẽ hoạt động như thế nào trong tương lai. Mô hình này cũng đang được tích cực khám phá và cho đến nay vẫn chưa có cách triển khai chính xác nào, yêu cầu của xã hội đối với các lập trình viên không đơn giản như công nghệ. Hiện nay, trở thành một lập trình viên am hiểu kinh doanh đang là xu hướng chung.

     。

  。

  。

    。

Tái bút: Một mặt, nhiều ý kiến ​​trên được tôi tổng hợp lại, mặt khác được mượn từ cuốn sách “Phoenix Architecture – Building Đáng Tin cậy Hệ thống phân tán quy mô lớn”. Tôi phải nói rằng cuốn sách này thực sự rất hay. dày, Chu Chí Minh Thầy thực sự rất mạnh mẽ. Đây là trải nghiệm đầu tiên của tôi khi đọc cuốn sách này, tôi hy vọng mình có thể tiếp tục đọc cuốn sách này và viết thêm những trải nghiệm trong cuộc sống công việc bận rộn của mình.

Cuối cùng, bài viết về Brief Talk: The Evolution of Service Architecture kết thúc tại đây. Nếu bạn muốn biết thêm về Brief Talk: The Evolution of Service Architecture, vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt các bài viết liên quan. trong tương lai! .