Vào ngày 25 tháng XNUMX, chúng tôi tại Tập đoàn Mail.ru đã tổ chức một hội nghị về mây và xung quanh - . Một vài điểm nổi bật:
- chính — Giải pháp đám mây Mail.ru, #CloudMTS, SberCloud, Selectel, Trung tâm dữ liệu Rostelecom và Yandex.Cloud đã nói về các chi tiết cụ thể của thị trường đám mây của chúng tôi và các dịch vụ của họ;
- Các đồng nghiệp từ Bitrix24 đã kể về cách họ ;
- Leroy Merlin, Otkritie, Burger King và Schneider Electric mang đến những điều thú vị — doanh nghiệp của họ đặt ra những nhiệm vụ gì cho CNTT và những công nghệ nào, bao gồm cả công nghệ đám mây, được họ coi là hứa hẹn nhất.
Bạn có thể xem tất cả các video từ hội nghị mailto:CLOUD và tại đây bạn có thể đọc cuộc thảo luận về microservice đã diễn ra như thế nào. Alexander Deulin, người đứng đầu trung tâm nghiên cứu và phát triển hệ thống kinh doanh MegaFon, và Sergey Sergeev, giám đốc công nghệ thông tin của nhóm M.Video-Eldorado, đã chia sẻ những trường hợp thành công của họ trong việc loại bỏ nguyên khối. Chúng tôi cũng thảo luận các vấn đề liên quan đến chiến lược, quy trình CNTT và thậm chí cả nhân sự.
tham luận viên
- Sergey Sergeev, Tập đoàn CIO "M.Video-Eldorado";
- Alexander Deulin, Giám đốc Trung tâm Nghiên cứu và Phát triển hệ thống kinh doanh MegaFon;
- Người điều hành — Dmitry Lazarenko, Trưởng phòng chỉ đạo PaaS Giải pháp đám mây Mail.ru.
Sau bài phát biểu của Alexander Deulin anh ấy tham gia thảo luận cùng với Sergey Sergeev từ M.Video-Eldorado và người điều hành cuộc thảo luận Dmitry Lazarenko, Mail.ru Cloud Solutions.
Dưới đây chúng tôi đã chuẩn bị bản ghi cuộc thảo luận cho bạn, nhưng bạn cũng có thể xem video:
Việc chuyển đổi sang microservice là sự đáp ứng nhu cầu của thị trường
Dmitriy:
Bạn đã có kinh nghiệm thành công nào khi di chuyển sang microservice chưa? Và nói chung: bạn thấy lợi ích kinh doanh lớn nhất ở đâu khi sử dụng vi dịch vụ hoặc chuyển từ nguyên khối sang vi dịch vụ?
Serge:
Chúng tôi đã đạt được một số thành tựu trong quá trình chuyển đổi sang microservice và đã sử dụng phương pháp này trong hơn ba năm. Nhu cầu đầu tiên chứng minh sự cần thiết của microservice là sự tích hợp vô tận của nhiều sản phẩm front-end khác nhau với bộ phận hỗ trợ. Và mỗi lần như vậy, chúng tôi buộc phải thực hiện tích hợp và phát triển bổ sung, thực hiện các quy tắc riêng của mình để vận hành dịch vụ này hoặc dịch vụ kia.
Tại một thời điểm nào đó, chúng tôi nhận ra rằng chúng tôi cần tăng tốc độ hoạt động của hệ thống và đầu ra của chức năng. Vào thời điểm đó, các khái niệm như microservice và cách tiếp cận microservice đã tồn tại trên thị trường và chúng tôi quyết định thử nó. Điều này bắt đầu vào năm 2016. Sau đó, nền tảng được đặt và 10 dịch vụ đầu tiên được triển khai bởi một nhóm riêng biệt.
Một trong những dịch vụ đầu tiên, nặng nề nhất là dịch vụ tính giá. Mỗi khi bạn đến bất kỳ kênh nào, đến tập đoàn công ty M.Video-Eldorado, dù là website hay cửa hàng bán lẻ, chọn sản phẩm tại đó, xem giá trên website hoặc trong “Giỏ”, chi phí sẽ tự động được tính. tính theo một dịch vụ. Tại sao điều này lại cần thiết: trước đó, mỗi hệ thống đều có những nguyên tắc riêng khi thực hiện các chương trình khuyến mãi - giảm giá, v.v. Văn phòng hỗ trợ của chúng tôi xử lý việc định giá; chức năng giảm giá được triển khai trong một hệ thống khác. Điều này cần phải được tập trung hóa và một dịch vụ duy nhất, có thể tách biệt được tạo ra dưới dạng một quy trình kinh doanh cho phép chúng tôi thực hiện điều này. Đó gần như là cách chúng tôi bắt đầu.
Giá trị của kết quả đầu tiên là rất lớn. Đầu tiên, chúng tôi có thể tạo các thực thể có thể tách rời cho phép chúng tôi làm việc riêng biệt và theo cách tổng hợp. Thứ hai, chúng tôi đã giảm chi phí sở hữu nhờ tích hợp với nhiều hệ thống hơn.
Trong ba năm qua, chúng tôi đã bổ sung thêm ba hệ thống tiền tuyến. Rất khó để duy trì họ với cùng lượng nguồn lực mà công ty có thể chi trả. Vì vậy, nhiệm vụ đặt ra là tìm kiếm những đầu ra mới, đáp ứng thị trường về tốc độ, chi phí nội bộ và hiệu quả.
Cách đo lường sự thành công của việc di chuyển sang microservice
Dmitriy:
Thành công trong việc chuyển đổi sang microservices được quyết định như thế nào? “Trước đây” ở mỗi công ty là gì? Bạn đã sử dụng số liệu nào để xác định sự thành công của quá trình chuyển đổi và ai thực sự đã xác định nó?
Serge:
Trước hết, nó được sinh ra trong lĩnh vực CNTT với vai trò là yếu tố hỗ trợ - “mở khóa” các khả năng mới. Chúng tôi cần phải làm mọi thứ nhanh hơn với cùng số tiền, đáp ứng những thách thức của thị trường. Giờ đây, thành công được thể hiện ở số lượng dịch vụ được các hệ thống khác nhau sử dụng lại, sự thống nhất các quy trình giữa chúng. Bây giờ thì đúng như vậy, nhưng tại thời điểm đó, đó là cơ hội để tạo ra một nền tảng và xác nhận giả thuyết rằng chúng ta có thể làm được điều này, nó sẽ mang lại hiệu quả và tính toán được trường hợp kinh doanh.
Alexander:
Thành công đúng hơn là một cảm giác bên trong. Doanh nghiệp luôn muốn nhiều hơn nữa và số lượng hồ sơ tồn đọng của chúng tôi là bằng chứng cho sự thành công. Đối với tôi có vẻ như vậy.
Serge:
Vâng tôi đồng ý. Trong ba năm, chúng tôi đã có hơn hai trăm dịch vụ và tồn đọng. Nhu cầu về nguồn lực trong nhóm chỉ tăng lên - 30% mỗi năm. Điều này xảy ra bởi vì mọi người cảm thấy: nó nhanh hơn, khác biệt hơn, có nhiều công nghệ khác nhau, tất cả đều đang phát triển.
Microservices sẽ xuất hiện nhưng cốt lõi vẫn sẽ tồn tại
Dmitriy:
Nó giống như một quá trình không bao giờ kết thúc khi bạn đầu tư vào phát triển. Quá trình chuyển đổi sang microservice cho doanh nghiệp đã kết thúc hay chưa?
Serge:
Nó rất dễ dàng để trả lời. Bạn nghĩ sao: thay thế điện thoại là một quá trình vô tận? Bản thân chúng tôi mua điện thoại hàng năm. Và đây là: chỉ cần có nhu cầu về tốc độ, để thích ứng với thị trường thì sẽ cần phải có một số thay đổi. Điều này không có nghĩa là chúng ta từ bỏ những điều tiêu chuẩn.
Nhưng chúng ta không thể che đậy và làm lại mọi thứ cùng một lúc. Chúng tôi có các dịch vụ tích hợp tiêu chuẩn, truyền thống đã tồn tại trước đây: xe buýt doanh nghiệp, v.v. Nhưng có tồn đọng, và cũng có nhu cầu. Số lượng ứng dụng di động và chức năng của chúng ngày càng tăng. Đồng thời, không ai nói rằng bạn sẽ được thưởng thêm 30% tiền. Nghĩa là, một mặt luôn có nhu cầu và mặt khác là tìm kiếm hiệu quả.
Dmitriy:
Cuộc sống đang trong tình trạng tốt. (Cười)
Alexander:
Nói chung là có. Chúng tôi không có những cách tiếp cận mang tính cách mạng để loại bỏ phần cốt lõi khỏi cảnh quan. Công việc có hệ thống đang được tiến hành để phân rã các hệ thống sao cho chúng phù hợp hơn với kiến trúc microservice, nhằm giảm ảnh hưởng của các hệ thống lên nhau.
Nhưng chúng tôi dự định giữ lại phần cốt lõi, vì trong bối cảnh của nhà điều hành sẽ luôn có một số nền tảng mà chúng tôi mua. Một lần nữa, chúng ta cần một sự cân bằng lành mạnh: chúng ta không nên vội vàng cắt bỏ phần cốt lõi. Chúng tôi đặt các hệ thống cạnh nhau và bây giờ hóa ra là chúng tôi đã kiểm soát được nhiều bộ phận cốt lõi. Hơn nữa, khi phát triển chức năng, chúng tôi tạo ra các đại diện cần thiết cho tất cả các kênh hoạt động với các dịch vụ liên lạc của chúng tôi.
Cách bán microservice cho doanh nghiệp
Dmitriy:
Tôi cũng quan tâm - dành cho những người chưa chuyển đổi nhưng đang có ý định: bán ý tưởng này cho doanh nghiệp dễ dàng như thế nào và đó có phải là một cuộc phiêu lưu, một dự án đầu tư không? Hay đó là một chiến lược có ý thức: bây giờ chúng ta sẽ chuyển sang microservices và thế là xong, không có gì có thể ngăn cản chúng ta. Làm thế nào là nó cho bạn?
Serge:
Chúng tôi không bán một cách tiếp cận mà là một lợi ích kinh doanh. Có một vấn đề trong kinh doanh và chúng tôi đã cố gắng giải quyết nó. Vào thời điểm đó, nó được thể hiện ở chỗ các kênh khác nhau sử dụng các nguyên tắc tính giá khác nhau - riêng cho các chương trình khuyến mãi, cho các chương trình khuyến mãi, v.v. Rất khó để bảo trì, xảy ra lỗi và chúng tôi đã lắng nghe khiếu nại của khách hàng. Nghĩa là, chúng tôi đang bán giải pháp cho một vấn đề, nhưng chúng tôi nhận ra rằng chúng tôi cần tiền để tạo ra một nền tảng. Và họ đã đưa ra một trường hợp kinh doanh bằng cách sử dụng ví dụ về giai đoạn đầu tư đầu tiên: chúng tôi sẽ tiếp tục thu hồi vốn như thế nào và điều này sẽ cho phép chúng tôi làm gì.
Dmitriy:
Bạn bằng cách nào đó đã ghi lại thời gian của giai đoạn đầu tiên?
Serge:
Vâng, chắc chắn rồi. Chúng tôi đã phân bổ 6 tháng để tạo ra phần lõi làm nền tảng và thử nghiệm chương trình thí điểm. Trong thời gian này, chúng tôi đã cố gắng tạo ra một nền tảng để phi công trượt băng trên đó. Sau đó, giả thuyết đã được xác nhận và vì nó hoạt động nên có nghĩa là chúng ta có thể tiếp tục. Họ bắt đầu nhân rộng và củng cố đội ngũ - họ chuyển nó thành một bộ phận riêng biệt để thực hiện công việc đó.
Tiếp theo là công việc có hệ thống dựa trên nhu cầu kinh doanh, cơ hội, nguồn lực sẵn có và mọi thứ hiện đang được thực hiện.
Dmitriy:
ĐƯỢC RỒI. Alexander, bạn nói gì?
Alexander:
Các microservice của chúng tôi ra đời từ “bọt biển” - do tiết kiệm tài nguyên, do dư thừa một số dung lượng máy chủ và sự phân bổ lại lực lượng trong nhóm. Ban đầu, chúng tôi không bán dự án này cho doanh nghiệp. Đây là một dự án mà cả hai chúng tôi đều nghiên cứu và phát triển phù hợp. Chúng tôi bắt đầu vào đầu năm 2018 và chỉ đơn giản là phát triển hướng đi này với sự nhiệt tình. Việc bán hàng chỉ mới bắt đầu và chúng tôi đang trong quá trình này.
Dmitriy:
Có phải doanh nghiệp cho phép bạn làm những việc như Google - vào một ngày rảnh rỗi trong tuần không? Bạn có định hướng như vậy không?
Alexander:
Đồng thời với việc nghiên cứu, chúng tôi cũng giải quyết các vấn đề kinh doanh, vì vậy tất cả các dịch vụ vi mô của chúng tôi đều là giải pháp cho các vấn đề kinh doanh. Chỉ mới bắt đầu, chúng tôi đã xây dựng các dịch vụ vi mô bao phủ một phần nhỏ cơ sở người đăng ký và hiện tại chúng tôi đã có mặt ở hầu hết các sản phẩm chủ lực.
Và tác động trọng yếu đã rõ ràng - chúng ta đã có thể tính toán được, tốc độ ra mắt sản phẩm và doanh thu bị mất có thể ước tính được nếu chúng ta đi theo con đường cũ. Đây là những gì chúng tôi đang xây dựng trường hợp trên.
Microservices: cường điệu hay cần thiết?
Dmitriy:
Con số là con số. Và doanh thu hoặc số tiền tiết kiệm được là rất quan trọng. Nếu bạn nhìn sang phía bên kia thì sao? Có vẻ như microservice đang là xu hướng, là sự cường điệu và nhiều công ty đang lạm dụng nó? Bạn phân biệt rõ ràng những gì bạn làm và không chuyển sang microservices? Nếu di sản bây giờ, liệu 5 năm nữa bạn có còn di sản không? Độ tuổi của hệ thống thông tin hoạt động tại M.Video-Eldorado và MegaFon sau 5 năm nữa là bao nhiêu? Sẽ có những hệ thống thông tin mười năm, mười lăm tuổi hay sẽ là một thế hệ mới? Bạn thấy điều này thế nào?
Serge:
Với tôi, dường như thật khó để nghĩ xa xôi. Nếu nhìn lại, ai có thể tưởng tượng được rằng thị trường công nghệ sẽ phát triển theo hướng này, bao gồm cả machine learning và nhận dạng người dùng bằng khuôn mặt? Nhưng nếu bạn nhìn vào những năm tới, đối với tôi, có vẻ như các hệ thống cốt lõi, hệ thống cấp doanh nghiệp ERP trong các công ty - chúng đã hoạt động được khá lâu.
Các công ty của chúng tôi có tổng cộng 25 năm tuổi, với hệ thống ERP cổ điển rất sâu sắc trong bối cảnh hệ thống. Rõ ràng là chúng tôi đang lấy một số phần ra khỏi đó và cố gắng tổng hợp chúng thành các dịch vụ vi mô, nhưng phần cốt lõi sẽ vẫn còn. Bây giờ tôi khó có thể tưởng tượng rằng chúng tôi sẽ thay thế tất cả các hệ thống cốt lõi ở đó và nhanh chóng chuyển sang mặt khác, mặt sáng sủa của các hệ thống mới.
Tôi ủng hộ thực tế rằng mọi thứ gần gũi hơn với khách hàng và người tiêu dùng đều là nơi mang lại lợi ích và giá trị kinh doanh lớn nhất, nơi có khả năng thích ứng và tập trung vào tốc độ, vào sự thay đổi, vào việc “thử, hủy, tái sử dụng, làm điều gì đó khác biệt” cần thiết “—đó là nơi mà cảnh quan sẽ thay đổi. Và các sản phẩm đóng hộp không vừa vặn ở đó. Ít nhất là chúng ta không nhìn thấy nó. Ở đó cần có những giải pháp đơn giản nhất, dễ dàng nhất.
Chúng tôi thấy sự phát triển này:
- hệ thống thông tin cốt lõi (chủ yếu là văn phòng hỗ trợ);
- các lớp trung gian dưới dạng microservice kết nối lõi, tổng hợp, tạo bộ nhớ đệm, v.v.;
- hệ thống tiền tuyến hướng tới người tiêu dùng;
- một lớp tích hợp thường được tích hợp vào thị trường, các hệ thống và hệ sinh thái khác. Lớp này càng nhẹ càng tốt, đơn giản và chứa tối thiểu logic nghiệp vụ.
Nhưng đồng thời, tôi cũng ủng hộ việc tiếp tục sử dụng các nguyên tắc cũ nếu chúng được sử dụng phù hợp.
Giả sử bạn có một hệ thống doanh nghiệp cổ điển. Nó nằm trong bối cảnh của một nhà cung cấp và bao gồm hai mô-đun hoạt động với nhau. Ngoài ra còn có một giao diện tích hợp tiêu chuẩn. Tại sao phải làm lại và mang microservice đến đó?
Nhưng khi có 5 mô-đun ở văn phòng hỗ trợ, từ đó các mẩu thông tin được thu thập vào quy trình kinh doanh, sau đó được 8-10 hệ thống tuyến đầu sử dụng, lợi ích sẽ được nhận thấy ngay lập tức. Bạn lấy từ năm hệ thống văn phòng hỗ trợ và tạo ra một dịch vụ, một dịch vụ biệt lập, tập trung vào quy trình kinh doanh. Làm cho dịch vụ trở nên tiên tiến về mặt công nghệ - để dịch vụ lưu trữ thông tin vào bộ nhớ đệm và có khả năng chịu lỗi, đồng thời hoạt động với các tài liệu hoặc tổ chức kinh doanh. Và bạn tích hợp nó theo một nguyên tắc duy nhất với tất cả các sản phẩm tiền tuyến. Họ đã hủy sản phẩm tiền tuyến - họ chỉ đơn giản là tắt tích hợp. Ngày mai bạn cần viết một ứng dụng di động hoặc tạo một trang web nhỏ và chỉ đưa một phần vào chức năng - mọi thứ đều đơn giản: bạn tập hợp nó giống như một công cụ xây dựng. Tôi thấy nhiều sự phát triển hơn theo hướng này - ít nhất là ở nước ta.
Alexander:
Sergey đã mô tả đầy đủ cách tiếp cận của chúng tôi, cảm ơn bạn. Tôi sẽ chỉ nói nơi chúng tôi chắc chắn sẽ không đi - đến phần cốt lõi, chủ đề thanh toán trực tuyến. Nghĩa là, trên thực tế, xếp hạng và tính phí sẽ vẫn là một máy tuốt lúa “lớn” sẽ ghi nợ một cách đáng tin cậy. Và hệ thống này sẽ tiếp tục được chứng nhận bởi các cơ quan quản lý của chúng tôi. Tất nhiên, mọi thứ khác hướng tới khách hàng đều là microservice.
Dmitriy:
Ở đây chứng nhận là một câu chuyện. Có lẽ sẽ được hỗ trợ nhiều hơn. Nếu bạn chi ít cho việc hỗ trợ hoặc hệ thống không yêu cầu hỗ trợ và sửa đổi thì tốt hơn hết bạn không nên động đến nó. Một sự thỏa hiệp hợp lý.
Cách phát triển microservice đáng tin cậy
Dmitriy:
Khỏe. Nhưng tôi vẫn quan tâm. Bây giờ bạn đang kể một câu chuyện thành công: mọi thứ đều ổn, chúng tôi chuyển sang microservices, bảo vệ ý tưởng cho doanh nghiệp và mọi thứ đã diễn ra tốt đẹp. Nhưng tôi đã nghe những câu chuyện khác.
Cách đây vài năm, một công ty Thụy Sĩ đã đầu tư hai năm vào việc phát triển nền tảng dịch vụ vi mô mới cho các ngân hàng cuối cùng đã đóng cửa dự án. Đã sụp đổ hoàn toàn. Nhiều triệu franc Thụy Sĩ đã được chi ra, và cuối cùng đội đã bị giải tán - mọi chuyện không thành công.
Bạn đã có những câu chuyện tương tự? Có hoặc có khó khăn gì không? Ví dụ, việc duy trì microservice và giám sát cũng là vấn đề đau đầu trong hoạt động vận hành của công ty. Rốt cuộc, số lượng thành phần tăng lên hàng chục lần. Bạn thấy thế nào, có những ví dụ đầu tư không thành công ở đây không? Và bạn có thể khuyên mọi người điều gì để không gặp phải những vấn đề như vậy?
Alexander:
Những ví dụ không thành công bao gồm việc doanh nghiệp thay đổi ưu tiên và hủy bỏ dự án. Khi ở giai đoạn sẵn sàng tốt (trên thực tế, MVP đã sẵn sàng), doanh nghiệp cho biết: “Chúng tôi có những ưu tiên mới, chúng tôi đang chuyển sang một dự án khác và chúng tôi sẽ kết thúc dự án này”.
Chúng tôi không gặp phải bất kỳ thất bại toàn cầu nào với microservice. Chúng tôi ngủ yên, chúng tôi có ca trực 24/7 phục vụ toàn bộ BSS [hệ thống hỗ trợ kinh doanh].
Và một điều nữa - chúng tôi cho thuê microservice theo quy định áp dụng cho sản phẩm đóng hộp. Chìa khóa thành công là trước tiên bạn cần tập hợp một nhóm sẽ chuẩn bị đầy đủ dịch vụ vi mô để sản xuất. Bản thân sự phát triển có điều kiện là 40%. Phần còn lại là phân tích, phương pháp DevSecOps, tích hợp phù hợp và kiến trúc phù hợp. Chúng tôi đặc biệt chú ý đến các nguyên tắc xây dựng ứng dụng an toàn. Các đại diện bảo mật thông tin tham gia vào từng dự án cả ở giai đoạn lập kế hoạch kiến trúc và trong quá trình thực hiện. Họ cũng quản lý các hệ thống phân tích mã để tìm lỗ hổng.
Giả sử chúng tôi triển khai các dịch vụ không trạng thái của mình - chúng tôi có chúng trong Kubernetes. Điều này cho phép mọi người có giấc ngủ yên bình nhờ khả năng tự động mở rộng quy mô và tự động nâng cao dịch vụ, đồng thời ca trực sẽ phát sinh sự cố.
Trong toàn bộ quá trình tồn tại của các dịch vụ vi mô của chúng tôi, chỉ có một hoặc hai sự cố xảy ra với đường dây của chúng tôi. Bây giờ không có vấn đề gì với hoạt động. Tất nhiên, chúng tôi không có 200 mà có khoảng 50 dịch vụ vi mô, nhưng chúng được sử dụng trong các sản phẩm chủ lực. Nếu họ thất bại, chúng ta sẽ là người đầu tiên biết về điều đó.
Dịch vụ vi mô và nhân sự
Serge:
Tôi đồng ý với đồng nghiệp về việc chuyển sang hỗ trợ - rằng công việc cần được tổ chức hợp lý. Nhưng tôi sẽ cho bạn biết về những vấn đề tất nhiên tồn tại.
Thứ nhất, công nghệ này mới. Đây là sự cường điệu theo một cách tích cực và việc tìm được một chuyên gia hiểu và có thể tạo ra điều này là một thách thức lớn. Sự cạnh tranh về tài nguyên rất điên rồ, vì vậy các chuyên gia có giá trị như vàng.
Thứ hai, với việc tạo ra những cảnh quan nhất định và số lượng dịch vụ ngày càng tăng, vấn đề tái sử dụng phải không ngừng được giải quyết. Như các nhà phát triển thường làm: “Bây giờ chúng ta hãy viết nhiều điều thú vị ở đây…” Vì điều này, hệ thống phát triển và mất đi tính hiệu quả về mặt tiền bạc, chi phí sở hữu, v.v. Tức là cần đưa tính tái sử dụng vào kiến trúc hệ thống, đưa nó vào lộ trình giới thiệu dịch vụ và chuyển giao di sản sang kiến trúc mới.
Một vấn đề khác - mặc dù điều này cũng tốt theo cách riêng của nó - là cạnh tranh nội bộ. “Ồ, những anh chàng thời trang mới đã xuất hiện ở đây, họ nói một ngôn ngữ mới.” Tất nhiên, mọi người đều khác nhau. Có những người đã quen viết bằng Java và có những người viết và sử dụng Docker và Kubernetes. Đây là những người hoàn toàn khác nhau, họ nói khác nhau, dùng những thuật ngữ khác nhau và đôi khi không hiểu nhau. Khả năng hoặc không có khả năng chia sẻ thực tiễn, chia sẻ kiến thức, theo nghĩa này cũng là một vấn đề.
Vâng, nhân rộng tài nguyên. “Tuyệt, đi thôi! Và bây giờ chúng tôi muốn nhanh hơn, nhiều hơn nữa. Cái gì, bạn không thể? Không thể giao hàng gấp đôi trong một năm sao? Và tại sao?" Những cơn đau ngày càng tăng như vậy có lẽ là tiêu chuẩn cho nhiều thứ, nhiều cách tiếp cận và bạn có thể cảm nhận được chúng.
Về giám sát. Đối với tôi, có vẻ như các dịch vụ hoặc công cụ giám sát công nghiệp đã được học hoặc có thể hoạt động với cả Docker và Kubernetes ở một chế độ khác, không chuẩn. Vì vậy, ví dụ, bạn không kết thúc với 500 máy Java trong đó tất cả những thứ này đang chạy, cụ thể là, nó tổng hợp lại. Nhưng những sản phẩm này vẫn chưa trưởng thành, chúng phải trải qua điều này. Chủ đề này thực sự mới, nó sẽ tiếp tục phát triển.
Dmitriy:
Vâng, rất thú vị. Và điều này áp dụng cho nhân sự. Có lẽ quy trình nhân sự và thương hiệu nhân sự của bạn đã thay đổi một chút trong 3 năm qua. Bạn bắt đầu tuyển dụng những người khác có năng lực khác nhau. Và có lẽ có cả ưu và nhược điểm. Trước đây, blockchain và khoa học dữ liệu là những thứ được quảng cáo rầm rộ và các chuyên gia trong lĩnh vực này có giá trị hàng triệu USD. Hiện tại, chi phí đang giảm, thị trường đang trở nên bão hòa và xu hướng tương tự đối với các dịch vụ vi mô.
Serge:
Phải, chắc chắn rồi.
Alexander:
Nhân sự đặt câu hỏi: “Con kỳ lân màu hồng của bạn ở đâu giữa phần phụ trợ và phần giao diện người dùng?” HR không hiểu microservice là gì. Chúng tôi đã nói cho họ biết bí mật và nói với họ rằng phần phụ trợ đã làm mọi thứ và không có con kỳ lân nào cả. Nhưng nhân sự đang thay đổi, học hỏi nhanh chóng và tuyển dụng những người có kiến thức cơ bản về CNTT.
Sự phát triển của microservice
Dmitriy:
Nếu bạn nhìn vào kiến trúc mục tiêu, microservice trông giống như một con quái vật. Cuộc hành trình của bạn mất vài năm. Những người khác có một năm, những người khác ba năm. Bạn có thấy trước tất cả các vấn đề, kiến trúc mục tiêu, có điều gì thay đổi không? Ví dụ: trong trường hợp vi dịch vụ, các cổng và lưới dịch vụ hiện đang xuất hiện trở lại. Bạn đã sử dụng chúng ngay từ đầu hay bạn đã thay đổi kiến trúc? Bạn có những thách thức như vậy?
Serge:
Chúng tôi đã viết lại một số giao thức liên lạc. Lúc đầu có một giao thức, bây giờ chúng tôi chuyển sang giao thức khác. Chúng tôi tăng cường sự an toàn và độ tin cậy. Chúng tôi bắt đầu với các công nghệ doanh nghiệp - Oracle, Web Logic. Bây giờ chúng tôi đang rời bỏ các sản phẩm doanh nghiệp công nghệ trong microservice và chuyển sang nguồn mở hoặc công nghệ mở hoàn toàn. Chúng tôi từ bỏ cơ sở dữ liệu và chuyển sang những gì hoạt động hiệu quả hơn với chúng tôi trong mô hình này. Chúng tôi không còn cần công nghệ của Oracle nữa.
Chúng tôi bắt đầu đơn giản như một dịch vụ mà không cần suy nghĩ về việc chúng tôi cần bao nhiêu bộ nhớ đệm, chúng tôi sẽ làm gì khi không có kết nối với vi dịch vụ nhưng cần có dữ liệu, v.v. Hiện chúng tôi đang phát triển một nền tảng để có thể mô tả kiến trúc không phải bằng ngôn ngữ dịch vụ mà bằng ngôn ngữ kinh doanh, hãy đưa logic kinh doanh lên một tầm cao mới khi chúng ta bắt đầu nói chuyện bằng lời nói. Bây giờ chúng ta đã học cách nói bằng chữ cái và cấp độ tiếp theo là khi các dịch vụ sẽ được thu thập thành một loại tổng hợp nào đó, khi đây đã là một từ - ví dụ: toàn bộ thẻ sản phẩm. Nó được tập hợp từ microservices, nhưng nó là một API được xây dựng dựa trên điều này.
An toàn là rất quan trọng. Ngay khi bạn bắt đầu có thể truy cập và bạn có một dịch vụ mà qua đó bạn có thể nhận được rất nhiều điều thú vị, và rất nhanh chóng, trong tích tắc, thì bạn sẽ có mong muốn có được nó theo cách không an toàn nhất. Để thoát khỏi điều này, chúng tôi đã phải thay đổi cách tiếp cận thử nghiệm và giám sát. Chúng tôi phải thay đổi đội ngũ, cơ cấu quản lý phân phối, CI/CD.
Đây là một sự tiến hóa - giống như điện thoại, chỉ nhanh hơn nhiều: đầu tiên là điện thoại nút bấm, sau đó điện thoại thông minh xuất hiện. Họ viết lại và thiết kế lại sản phẩm vì thị trường có nhu cầu khác. Đây là cách chúng ta phát triển: lớp một, lớp mười, công việc.
Lặp đi lặp lại, một cái gì đó được đặt ra mỗi năm từ quan điểm của công nghệ, một cái gì đó khác từ quan điểm tồn đọng và nhu cầu. Chúng tôi kết nối cái này với cái khác. Nhóm dành 20% cho nợ kỹ thuật và hỗ trợ kỹ thuật cho nhóm, 80% cho đơn vị kinh doanh. Và chúng tôi hành động với sự hiểu biết về lý do tại sao chúng tôi làm điều đó, tại sao chúng tôi thực hiện những cải tiến công nghệ này, chúng sẽ dẫn đến điều gì. Như thế.
Dmitriy:
Mát mẻ. Có gì trong MegaFon?
Alexander:
Thử thách chính khi chúng tôi đến với microservice là không rơi vào tình trạng hỗn loạn. Văn phòng kiến trúc MegaFon ngay lập tức tham gia cùng chúng tôi, thậm chí còn trở thành người khởi xướng và điều khiển - giờ đây chúng tôi đã có một kiến trúc rất vững mạnh. Nhiệm vụ của anh ấy là hiểu mô hình mục tiêu mà chúng tôi sẽ hướng tới và những công nghệ nào cần được thử nghiệm. Với kiến trúc, chúng tôi đã tự mình thực hiện những thử nghiệm này.
Câu hỏi tiếp theo là: “Vậy làm thế nào để khai thác tất cả những điều này?” Và một điều nữa: “Làm cách nào để đảm bảo sự tương tác minh bạch giữa các microservice?” Lưới dịch vụ đã giúp chúng tôi trả lời câu hỏi cuối cùng. Chúng tôi đã thử nghiệm Istio và thích kết quả. Bây giờ chúng tôi đang ở giai đoạn triển khai các vùng sản xuất. Chúng tôi có thái độ tích cực trước mọi thử thách - thực tế là chúng tôi cần liên tục thay đổi phương pháp, học hỏi điều gì đó mới. Chúng tôi quan tâm phát triển chứ không khai thác các giải pháp cũ.
Dmitriy:
Lời vàng! Những thách thức như vậy giúp nhóm và doanh nghiệp luôn nỗ lực và tạo ra tương lai. GDPR đã tạo ra các giám đốc bảo vệ dữ liệu và những thách thức hiện tại tạo ra các giám đốc kiến trúc và dịch vụ vi mô. Và nó làm hài lòng.
Chúng tôi đã thảo luận rất nhiều. Điều chính là thiết kế tốt các microservices và bản thân kiến trúc sẽ cho phép bạn tránh được nhiều sai lầm. Tất nhiên, quá trình này lặp đi lặp lại và tiến hóa, nhưng đó là tương lai.
Cảm ơn tất cả những người tham gia, cảm ơn Sergei và Alexander!
Câu hỏi từ khán giả
Câu hỏi của khán giả (1):
Sergey, việc quản lý CNTT ở công ty của bạn đã thay đổi như thế nào? Tôi hiểu rằng khi có một lượng lớn nhiều hệ thống, cách quản lý nó là một quy trình khá rõ ràng và hợp lý. Bạn đã xây dựng lại việc quản lý thành phần CNTT như thế nào sau khi một số lượng rất lớn dịch vụ vi mô được tích hợp trong một thời gian ngắn như vậy?
Serge:
Tôi đồng ý với đồng nghiệp của mình rằng kiến trúc đóng vai trò rất quan trọng với tư cách là động lực của sự thay đổi. Chúng tôi bắt đầu bằng việc có một bộ phận kiến trúc. Kiến trúc sư đồng thời là người nắm giữ quyền phân bổ chức năng và các yêu cầu về cách thức nó xuất hiện trong cảnh quan. Vì vậy họ cũng đóng vai trò là người điều phối những thay đổi này. Do đó, đã có những thay đổi cụ thể đối với quy trình phân phối cụ thể khi chúng tôi tạo nền tảng CI/CD.
Nhưng các nguyên tắc cơ bản, tiêu chuẩn về phát triển, phân tích kinh doanh, thử nghiệm và phát triển vẫn chưa bị hủy bỏ. Chúng tôi vừa thêm tốc độ. Trước đây, chu trình mất rất nhiều thời gian, việc cài đặt trên môi trường thử nghiệm mất nhiều thời gian hơn. Bây giờ doanh nghiệp nhìn thấy lợi ích và nói: “Tại sao chúng ta không thể làm điều tương tự ở những nơi khác?”
Nói một cách tích cực, nó giống như một mũi tiêm dưới dạng vắc xin cho thấy: bạn có thể làm theo cách này nhưng bạn có thể làm theo cách khác. Tất nhiên, có vấn đề về nhân sự, năng lực, kiến thức, khả năng phản kháng.
Câu hỏi của khán giả (2):
Những người chỉ trích kiến trúc microservice cho rằng việc thử nghiệm và phát triển rất khó khăn. Điều này hợp lý khi mọi thứ trở nên phức tạp. Nhóm của bạn đã gặp phải những thách thức gì và bạn đã vượt qua chúng như thế nào? Câu hỏi dành cho mọi người.
Alexander:
Có những khó khăn khi chuyển từ microservice sang nền tảng, nhưng chúng có thể được giải quyết.
Ví dụ: chúng tôi đang tạo ra một sản phẩm bao gồm 5-7 dịch vụ vi mô. Chúng tôi cần cung cấp các thử nghiệm tích hợp trên toàn bộ ngăn xếp vi dịch vụ để bật đèn xanh cho việc chuyển sang nhánh chính. Nhiệm vụ này không mới đối với chúng tôi: chúng tôi đã làm việc này từ lâu tại BSS, khi nhà cung cấp cung cấp cho chúng tôi các giải pháp đã được chuyển giao.
Và vấn đề của chúng tôi chỉ nằm ở đội ngũ nhỏ. Cần một kỹ sư QA cho một sản phẩm có điều kiện. Và vì vậy, chúng tôi xuất xưởng một sản phẩm gồm 5-7 vi dịch vụ, trong đó 2-3 vi dịch vụ có thể được phát triển bởi các bên thứ ba. Ví dụ: chúng tôi có một sản phẩm đang trong quá trình phát triển mà nhà cung cấp hệ thống thanh toán của chúng tôi, Mail.ru Group và MegaFon R&D tham gia. Chúng tôi cần phải kiểm tra vấn đề này trước khi đưa nó vào sản xuất. Kỹ sư QA đã làm việc trên sản phẩm này được một tháng rưỡi và những người còn lại trong nhóm không có sự hỗ trợ của anh ấy.
Sự phức tạp này chỉ được gây ra bởi việc mở rộng quy mô. Chúng tôi hiểu rằng microservice không thể tồn tại trong chân không; không tồn tại sự cô lập tuyệt đối. Khi thay đổi một dịch vụ, chúng tôi luôn cố gắng duy trì hợp đồng API. Nếu có điều gì đó thay đổi bên dưới mui xe, dịch vụ phía trước vẫn được giữ nguyên. Nếu những thay đổi nghiêm trọng, một số loại chuyển đổi kiến trúc sẽ diễn ra và chúng tôi chuyển sang một siêu mô hình dữ liệu hoàn toàn khác, siêu mô hình này hoàn toàn không tương thích - chỉ khi đó chúng ta mới nói về đặc tả API dịch vụ v2 xuất hiện. Chúng tôi hỗ trợ đồng thời phiên bản thứ nhất và thứ hai và sau khi tất cả người tiêu dùng chuyển sang phiên bản thứ hai, chúng tôi chỉ cần đóng phiên bản đầu tiên.
Serge:
Tôi muốn thêm vào. Tôi hoàn toàn đồng ý về những biến chứng - chúng xảy ra. Bối cảnh ngày càng trở nên phức tạp hơn và chi phí chung ngày càng tăng, đặc biệt là cho việc thử nghiệm. Cách giải quyết vấn đề này: chuyển sang thử nghiệm tự động. Có, bạn sẽ phải đầu tư thêm vào việc viết bài kiểm tra tự động và bài kiểm tra đơn vị. Vì vậy, các nhà phát triển không thể cam kết nếu không vượt qua bài kiểm tra, họ không thể thay đổi mã. Vì vậy, ngay cả nút ấn cũng không hoạt động nếu không có autotest, unit test.
Điều quan trọng là phải duy trì chức năng trước đó và đây là chi phí bổ sung. Nếu bạn viết lại một công nghệ sang một giao thức khác, thì bạn viết lại nó cho đến khi bạn đóng mọi thứ hoàn toàn.
Đôi khi chúng tôi không cố ý thực hiện thử nghiệm từ đầu đến cuối vì chúng tôi không muốn ngừng phát triển, mặc dù chúng tôi cũng có hết thứ này đến thứ khác. Cảnh quan rất rộng lớn, phức tạp, có nhiều hệ thống. Đôi khi nó chỉ là sơ khai - vâng, bạn hạ thấp giới hạn an toàn, sẽ xuất hiện nhiều rủi ro hơn. Nhưng đồng thời bạn giải phóng nguồn cung.
Alexander:
Có, kiểm tra tự động và kiểm tra đơn vị cho phép bạn tạo ra dịch vụ chất lượng cao. Chúng tôi ủng hộ một quy trình không thể vượt qua nếu không có các bài kiểm tra đơn vị và tích hợp. Chúng tôi thường phải kéo các trình giả lập và hệ thống thương mại vào vùng thử nghiệm và môi trường phát triển, bởi vì không phải tất cả hệ thống đều có thể được đặt trong vùng thử nghiệm. Hơn nữa, chúng không chỉ bị ướt - chúng tôi còn tạo ra phản hồi chính thức từ hệ thống. Đây là một phần quan trọng khi làm việc với microservice và chúng tôi cũng đang đầu tư vào nó. Nếu không có điều này, sự hỗn loạn sẽ xảy ra.
Câu hỏi của khán giả (3):
Theo tôi hiểu thì microservice ban đầu phát triển từ một nhóm riêng biệt và hiện tồn tại trong mô hình này. Ưu và nhược điểm của nó là gì?
Chúng ta cũng có một câu chuyện tương tự: một loại nhà máy sản xuất dịch vụ vi mô xuất hiện. Bây giờ về mặt khái niệm, chúng tôi đã đi đến mức chúng tôi đang mở rộng cách tiếp cận này sang sản xuất theo dòng và theo hệ thống. Nói cách khác, chúng ta đang rời xa sự phát triển tập trung của microservice, mô hình microservice và đang tiến gần hơn đến các hệ thống.
Theo đó, hoạt động của chúng tôi cũng đi đến các hệ thống, tức là chúng tôi đang phân cấp chủ đề này. Cách tiếp cận của bạn là gì và câu chuyện mục tiêu của bạn là gì?
Alexander:
Bạn đã bỏ ngay cái tên “nhà máy vi dịch vụ” ra khỏi miệng - chúng tôi cũng muốn mở rộng quy mô. Thứ nhất, bây giờ chúng tôi thực sự có một đội. Chúng tôi muốn cung cấp cho tất cả các nhóm phát triển mà MegaFon có cơ hội làm việc trong một hệ sinh thái chung. Chúng tôi không muốn tiếp quản hoàn toàn tất cả chức năng phát triển mà chúng tôi hiện có. Nhiệm vụ cục bộ là mở rộng quy mô, nhiệm vụ toàn cầu là dẫn dắt sự phát triển cho tất cả các nhóm trong lớp vi dịch vụ.
Serge:
Tôi sẽ cho bạn biết con đường chúng tôi đã đi. Chúng tôi thực sự đã bắt đầu làm việc như một đội, nhưng bây giờ chúng tôi không đơn độc. Tôi là người đề xuất điều sau: phải có chủ sở hữu của quy trình. Ai đó cần hiểu, quản lý, kiểm soát và xây dựng quy trình phát triển microservice. Anh ta phải sở hữu tài nguyên và tham gia quản lý tài nguyên.
Những nguồn lực này, những người biết công nghệ, chi tiết cụ thể và hiểu cách xây dựng các dịch vụ vi mô, có thể được bố trí trong nhóm sản phẩm. Chúng tôi có sự kết hợp trong đó những người từ nền tảng microservice tham gia vào nhóm sản phẩm tạo ra ứng dụng di động. Họ ở đó nhưng làm việc theo quy trình của bộ phận quản lý nền tảng microservice với người quản lý phát triển của họ. Trong bộ phận này có một nhóm riêng phụ trách công nghệ. Nghĩa là, chúng tôi trộn lẫn một nguồn tài nguyên chung giữa chúng tôi và phân chia chúng, đưa chúng cho các đội.
Đồng thời, quy trình vẫn mang tính tổng quát, được kiểm soát, nó tiến hành theo các nguyên tắc công nghệ chung, với thử nghiệm đơn vị, v.v. - mọi thứ đều được xây dựng từ đầu. Có thể có các cột ở dạng tài nguyên được thu thập từ các bộ phận khác nhau của cách tiếp cận sản phẩm.
Alexander:
Sergey, bạn thực sự là chủ sở hữu của quá trình này phải không? Công việc tồn đọng có được chia sẻ không? Ai chịu trách nhiệm phân phối nó?
Serge:
Hãy nhìn xem: đây lại là sự pha trộn. Có một tồn đọng được hình thành dựa trên những cải tiến công nghệ - đây là một câu chuyện. Có tồn đọng được hình thành từ các dự án và có tồn đọng từ sản phẩm. Nhưng trình tự giới thiệu từng sản phẩm dịch vụ hoặc việc tạo ra dịch vụ này đều do một chuyên gia về sản phẩm phát triển. Anh ấy không ở trong ban CNTT, anh ấy đã bị loại khỏi đó một cách đặc biệt. Nhưng người của tôi chắc chắn làm việc theo cùng một quy trình.
Chủ sở hữu của những hồ sơ tồn đọng theo những hướng khác nhau - những hồ sơ tồn đọng của những thay đổi - sẽ là những người khác nhau. Sự kết nối của các dịch vụ công nghệ, nguyên tắc tổ chức của chúng - tất cả những điều này sẽ có trong CNTT. Tôi cũng sở hữu nền tảng và tài nguyên. Ở trên cùng là những gì liên quan đến các thay đổi tồn đọng và chức năng cũng như kiến trúc theo nghĩa này.
Giả sử một doanh nghiệp nói: “Chúng tôi muốn chức năng này, chúng tôi muốn tạo ra một sản phẩm mới - làm lại một khoản vay”. Chúng tôi trả lời: “Có, chúng tôi sẽ làm lại.” Các kiến trúc sư nói: “Hãy suy nghĩ: chúng ta sẽ viết microservice ở đâu trong khoản vay và chúng ta sẽ thực hiện điều đó như thế nào?” Sau đó, chúng tôi chia nó thành các dự án, sản phẩm hoặc nhóm công nghệ, đưa vào các nhóm và triển khai. Bạn đã tạo một sản phẩm nội bộ và quyết định sử dụng microservice trong sản phẩm này chưa? Chúng tôi nói: “Bây giờ, các hệ thống cũ mà chúng tôi có hoặc các hệ thống tiền tuyến phải chuyển sang các dịch vụ vi mô này”. Các kiến trúc sư cho biết: “Vì vậy: trong lượng công nghệ tồn đọng bên trong các sản phẩm tiền tuyến - sự chuyển đổi sang dịch vụ vi mô. Đi". Và các chuyên gia sản phẩm hoặc chủ doanh nghiệp hiểu rõ năng lực được phân bổ là bao nhiêu, khi nào việc đó sẽ được thực hiện và tại sao.
Kết thúc cuộc thảo luận, nhưng không phải tất cả
Hội nghị mailto:CLOUD được tổ chức .
Chúng tôi cũng thực hiện các sự kiện khác - ví dụ: Cuộc gặp gỡ @Kubernetes, nơi chúng tôi luôn tìm kiếm những diễn giả tuyệt vời:
- Theo dõi @Kubernetes và các tin tức @Meetup khác trên kênh Telegram của chúng tôi
- Bạn muốn phát biểu tại một trong các @Meetups? Để lại yêu cầu cho
Nguồn: www.habr.com