Những điều thích nhất ở cách anh làm video : 1. Cách minh họa bằng hình ảnh, gif, animation, 2. Cách anh chèn sub vào những lúc anh nói (keyword quan trọng) 3. Giọng đọc quá là hay 4. Nội dung ngắn gọn, xúc tích, video nào ra video đấy không lan man, đi từ overview đến specific Một chút góp ý cho anh 1. Có thể tăng âm lượng của giọng anh lên một chút 2. Nên có phần tổng kết những phần quan trọng ở cuối video 3. Nên thêm reference cho những bạn cần tham khảo Đây là ý kiến cá nhân của em, hy vọng trong tương lai anh sẽ ra thêm nhiều video nữa nhé, ra khóa học chắc em đặt gạch luôn vì giọng hay quá Chúc anh nhiều sức khỏe và niềm vui ạ
Tks bạn đã chia sẽ. Mình từng làm dev microservices. Đúng như bạn nói, thực sự nó có rất nhiều ưu điểm và giúp cho chúng ta dễ dàng hơn trước về việc triển khai cũng như maintenance. Dưới góc nhìn của một developer mình xin bổ sung thêm một ý nhỏ để các bạn lựa chọn dễ dàng hơn. + Việc triển khai microservice vơi database có cấu trúc phức tạp là điều cần cân nhắc, thứ nhất là khi chúng define model trong từng microservice bị reuse code rất nhiều chẳng hạn microservice A sử dụng customer table thì chúng ta cần define structure nếu dùng ORM và sang microservice B cũng dùng customer table thì chúng ta lại phải copy code bưng qua , hơn nữa khi cần triển khai một tính năng mới ngoài việc sửa db, chúng ta cần đi kiếm tất cả những microservice nào có liên quan đến model vừa update(như cái customer table vừa nói), rất mất thời gian và khó chịu, nếu update k hết dễ dẫn đến bug khi call api k lấy đc data + Khó trong việc đồng bộ api version. Tưởng tượng bạn có 30 api mỗi lần update version bạn lại phải lên front-end update lại endpoind + Lời khuyên của mình là khi chia microservice k nên chia quá nhỏ vì sẽ dẫn đến nhiều và khó quản lý, những api nào gộp được thì cố gắng gộp , áp dụng tốt cho database không quá nhiều relationship, nosql.
Một mô hình mới ra đời để giải quyết vấn đề của mô hình cũ, nhưng bản thân nó cũng có những vấn đề. Không có mô hình nào là đúng trong mọi trường hợp. Chính vì thế mới cần planning. Và một mô hình phức tạp như ms thì càng cần planning cẩn thận. Cảm ơn bạn vì những góp ý mang tính xây dựng
vấn đề 1: với ví dụ bạn đưa ra thì mình nghĩ bạn đang implement sai cách, bạn k cần biết user model trông chi tiết như thế nào, thứ bạn cần là một userdto(liên quan tới abstraction in oop), bạn nên tìm hiểu về hexagon architecture in microservices vấn đề 2: mình k hiểu lắm, chẳng phải các thư viện như axios đều hỗ trợ versioning ổn sao vấn đề 3: bạn nên tìm hiểu ddd, các service nên chia theo domain, bounded context...
Một kiến thức nào muốn học đều cần thời gian , nhưng nếu học đúng nơi như video này chúng ta tiết kiệm được thời gian research và bắt tay vào luôn , Anh đưa tư duy vào để trình bày cực kỳ dể hiểu , súc tích. Thế thôi nhưng rất hiếm người làm được vậy.
Mình tin phần lớn các bạn xem vid này chưa từng làm việc với microservices trong thực tế nên khi nghe vid này cảm thấy rất thuyết phục. Nhưng nếu microservices thực sự thần thánh và dễ kiểm soát như vậy thì có lẽ công ty nào cũng đã triển khai nó rồi. Đừng thần thánh hoá công nghệ mà hãy tập trung vào giải quyết vấn đề, monolithic cũng có những ưu điểm của nó, microservices cũng vậy. Chọn một kiến trúc phù hợp cho business chứ không phải cứ lúc nào cũng microservices.
đối dự án lượng dữ liệu lớn, hay số lượng người dùng nhiều, hay những dự án sử lý nặng dùng cách chia để trị. còn các dự án nhỏ làm cho nó phức tạp😂😂😂 phần lớn lập trình viên sài rồi nhưng không biết là mình đang sài nó. như opentid hay payment, hay server web, server database.... hay các dự án chạy trên vài server, pc... đây hay làm các dự án view trên server, process trên 1 server khác. tùy vào dự án, trước làm mấy dự án web craw. mình sài cách này. vì phần craw nặng làm ảnh hưởng đến tốc dộ truy cập của website nên tách ra thành server riêng chạy.😂😂😂
Bạn nói chuẩn. Tùy dự án và tùy quy mô doanh nghiệp cũng như chi phí mà ta chọn microservices or monolithic. Nếu chỉ là 1 ứng dụng nhỏ thì làm monolithic cho mau ....
Thật tình cờ em cần tìm hiểu về docker thì youtube gợi ý video của anh, em thật sự ấn tượng cách anh nói, không lan man, minh họa dễ hiểu, giọng ấm và trầm. Rất mong anh sẽ tiếp tục ra video dài dài.Cảm ơn anh rất nhiều.
Thank bác nhiều nhen. Mình làm D.A mà ngồi trog phòng cùng với team Infra nên ăn suốt ngày nghe mấy thuật ngữ này hoài nhưg chả hiểu gì. Giờ thì có thể chém gió chút dc rùi
Respect bạn vì clip rất hay, animation cũng rất hợp nhãn. Nó còn hoàn hảo hơn nếu chúng ta có thể phát âm từ vựng chuẩn xác nữa. Bạn có thể tra trên google các từ như service, python... xem nó đọc như thế nào rồi phát âm lại cho đúng nhé😄
Nội dung rất hay và hữu ích, ngắn gọn, minh hoạ dễ hiểu, giọng đọc rất tốt. Hi vọng sắp tới anh sẽ tiếp tục chia sẻ các content về microservice, load balancing, ... 🥰
Mình là software dev cũng lâu , video rất hay và dể hiểu nhưng mà nên thêm chi tiết vào 1 tí để các bạn mới học sẽ dể nắm bắt hơn . Nhất là phần demo bạn đã bỏ qua bước giải thích service discovery trong các service của bạn nhảy thẳng vô luôn , đương nhiên tất cả mấy cái đó thằng K8s hỗ trợ hết rùi nhưng cũng nên giải thích á Đương nhiên đây là vấn đề của DevOPS , nhưng mà Dev BE cũng phải biết á . Đó là chưa nói đến việc bạn bỏ qua bước Database và bước Message Queue ( Hầu như microservice thì 2 thằng này là quan trọng cực kỳ ) . bất kỳ hệ thống nào . Việc setup Kafka hay RabbitMQ hay bất kỳ 1 queue sever trung gian nào cũng là 1 quá trình gian khổ kkk
Trong video mình có nói là microservices và K8s còn rất nhiều thứ để nói. Nhưng vì đây là video giới thiệu nên mình k muốn cho quá nhiều thông tin vì sẽ thành lan man. Nhưng cũng cảm ơn bạn vì nhận xét rất có tâm. Những video sau mình sẽ nói sâu hơn. Chờ nhé!!!
@@khalid_dinh à quên mất bạn là devOPS hay full stack hay như nào nhỉ . Do mình cũng dev Backend rùi biết thêm tí bên devOPS để dể triển khai thôi chứ cũng không phải chuyên gia vận hành kkk
Anh làm video về 1 sản phẩm thực tế triện khai như nào, xây dựng database ra sao vd cần 1 databse để read và 1 cái để write em thường nghe vậy, thiết kế code Vd design parttern , dùng thêm công cụ gì vd redis hay dùng nhiều cái gì đó. và cảm ơn anh vì video trên
Em chào anh, biết kênh anh qua các video trước có thấy anh nói kênh anh làm về python, nên e rất mong anh sẽ sớm có chuỗi video về chủ đề django ạ. Django tuy có nhiều ưu điểm nhưng em thấy đang ít công ty tuyển fresher, thêm vào đó là khóa học Django bằng tiếng Việt em theo trên UA-cam của em thấy nó khác ngoài thực tế rất nhiều, điển hình là việc cập nhật dữ liệu ạ. Không mong anh có thể làm một khóc học chi tiết mà chỉ mong có một video đưa ra được một roadmap đầy đủ về Django là cũng tuyệt vời rồi ạ. Cám ơn anh
vô mấy cty theo công nghệ cũ chán vãi . gọi là block Tech lun, mãi làm toàn ba cái công nghệ nhà mình , cái source thì qua 15 năm cả trăm thằng viết vô .noi chứ mĩnh vấn thích làm cty Product hơn.
Nếu mình gặp 1 ứng dụng đang sử dụng mô hình MVC có rất nhiều service module lớn, làm sao với 1 team 4 người mình có thể cover refactor lại toàn bộ thành Microservices? mình cần làm những bước nào và mất bao lâu? nhờ Khalid Dinh gợi ý giúp mình với
Coi video anh không hiểu sao cứ bị cuốn cuốn kiểu gì ấy. Sẵn tiện cho em hỏi là: Nếu chỉ sử dụng 1 máy chủ nhưng dùng docker để chia ra các service trong máy chủ đó thì có được xem là microservices không anh? Hay phải là nhiều server triển khai các services này thì mới coi là microservices?
triển khai lên container hay lên server nó là cách deploy thôi em. Microservices là về cách thiết kế kiến trúc của phần mềm. Nên ở câu hỏi của e thì về mặt lý thuyết thì vẫn gọi là microservices. Nhưng thực tế thì không ai chỉ dùng 1 server vì không có lợi về tính HA (High availability)
cho mình hỏi 1 hệ thống đc xem là monolithic phụ thuộc vào gì, ví dụ mình có nhiều service viết bằng nhiều ngôn ngữ khác nhau nhưng tất cả đều sài chung 1 database, vì khái niệm cơ bản của microservice mà mình hiểu thì mỗi 1 service sẽ có database riêng. vậy hệ thống này có đc xem là monolithic ko ?
monolithic thì không chia services, khi build thì chỉ tạo ra 1 artifact (VD 1 file .jar), nó cũng chỉ có 1 database. Microservices thì ngược lại. Về việc microservices có thể chỉ dùng 1 db hay k thì thực tế là vẫn có hệ thống như vậy. Tuy nhiên thiết kế như vậy phải bỏ đi các ưu điểm của microservices cho khối db: Scaling, High Availability, ... Dĩ nhiên việc thiết kế db trong microservices cũng phức tạp và khó hơn. Nó là bài toán cân đối lợi ích
Cho em hiện tại công ty em đang làm monolithic + nginx và test đổ tải khoảng 2-4 nghìn user sử dụng thì api bắt đầu có dấu hiện lỗi. Nếu chuyển qua microservice thì ví dụ việc call api 1 sản phẩm rồi sản phẩm đấy lại call 5 api đánh giá sản phẩm như ví dụ trên video, nó có khả năng bị quá tải nếu 1000 user call api sản phẩm (call 5000 api đánh giá sản phẩm) không ạ? Em là người mới nên mong được mọi người giải đáp ạ ^^
Vấn đề là cần biết tại sao nó lỗi. Nếu lỗi do thiếu tài nguyên thì cần tìm xem điểm nào trong chuỗi call API đang bị quá tải. Hay services nào đang được call nhiều. Rồi cấp thêm tài nguyên cho service đó bằng việc scaling. Đây là phương pháp chung cho cả monolithic và microservices. Microservices thì nó có lợi thế về monitoring + scaling + HA hơn nên việc phát hiện nút thắt, alert, scaling / modify cũng sẽ tiện hơn. Nhưng không có gì đảm bảo 100% khi chuyển sang microservices sẽ không bị quá tải. Quan trọng nhất vẫn là phát hiện đâu là nguyên nhân dẫn đến failure
Việc khối FE và BE riêng biệt, hầu như k phải là cách nhận biết 3 tiers hay microservices. Sự khác biệt lớn nằm ở các services và database của service ở BE có tách nhau k. Nếu có thì là MS, nếu k thì là monolithic. Còn hầu như mọi mô hình thì FE và BE vẫn được tách riêng.
@@khalid_dinh "chia" ở đây được hiểu theo nghĩa nào anh nhỉ, vì có vài architecture vẫn có thể gộp được cả FE và BE thành 1 block sau đó đẩy lên cloud service
@@brolynguyen3430 chia nghĩa là tách từ codebase, cách giao tiếp giữa các services, cách triển khai các service đó lên các server, cách tách database cho từng service. Nếu đáp ứng đủ thì là microservices. Còn k thì có thể là monolithic hoặc các kiểu trúc khác
Dev còn trụ được thì monolithic hay ms không còn quan trọng 🤣🤣🤣 Chưa chắc chuyển đổi sang ms đã ngon, quan trọng là phải phù hợp với tình hình và năng lực team nữa
Những điều thích nhất ở cách anh làm video :
1. Cách minh họa bằng hình ảnh, gif, animation,
2. Cách anh chèn sub vào những lúc anh nói (keyword quan trọng)
3. Giọng đọc quá là hay
4. Nội dung ngắn gọn, xúc tích, video nào ra video đấy không lan man, đi từ overview đến specific
Một chút góp ý cho anh
1. Có thể tăng âm lượng của giọng anh lên một chút
2. Nên có phần tổng kết những phần quan trọng ở cuối video
3. Nên thêm reference cho những bạn cần tham khảo
Đây là ý kiến cá nhân của em, hy vọng trong tương lai anh sẽ ra thêm nhiều video nữa nhé, ra khóa học chắc em đặt gạch luôn vì giọng hay quá
Chúc anh nhiều sức khỏe và niềm vui ạ
Cảm ơn bạn nhé
@@khalid_dinh respect
Tks bạn đã chia sẽ. Mình từng làm dev microservices. Đúng như bạn nói, thực sự nó có rất nhiều ưu điểm và giúp cho chúng ta dễ dàng hơn trước về việc triển khai cũng như maintenance. Dưới góc nhìn của một developer mình xin bổ sung thêm một ý nhỏ để các bạn lựa chọn dễ dàng hơn.
+ Việc triển khai microservice vơi database có cấu trúc phức tạp là điều cần cân nhắc, thứ nhất là khi chúng define model trong từng microservice bị reuse code rất nhiều chẳng hạn microservice A sử dụng customer table thì chúng ta cần define structure nếu dùng ORM và sang microservice B cũng dùng customer table thì chúng ta lại phải copy code bưng qua , hơn nữa khi cần triển khai một tính năng mới ngoài việc sửa db, chúng ta cần đi kiếm tất cả những microservice nào có liên quan đến model vừa update(như cái customer table vừa nói), rất mất thời gian và khó chịu, nếu update k hết dễ dẫn đến bug khi call api k lấy đc data
+ Khó trong việc đồng bộ api version. Tưởng tượng bạn có 30 api mỗi lần update version bạn lại phải lên front-end update lại endpoind
+ Lời khuyên của mình là khi chia microservice k nên chia quá nhỏ vì sẽ dẫn đến nhiều và khó quản lý, những api nào gộp được thì cố gắng gộp , áp dụng tốt cho database không quá nhiều relationship, nosql.
Một mô hình mới ra đời để giải quyết vấn đề của mô hình cũ, nhưng bản thân nó cũng có những vấn đề. Không có mô hình nào là đúng trong mọi trường hợp. Chính vì thế mới cần planning. Và một mô hình phức tạp như ms thì càng cần planning cẩn thận. Cảm ơn bạn vì những góp ý mang tính xây dựng
vấn đề 1: với ví dụ bạn đưa ra thì mình nghĩ bạn đang implement sai cách, bạn k cần biết user model trông chi tiết như thế nào, thứ bạn cần là một userdto(liên quan tới abstraction in oop), bạn nên tìm hiểu về hexagon architecture in microservices
vấn đề 2: mình k hiểu lắm, chẳng phải các thư viện như axios đều hỗ trợ versioning ổn sao
vấn đề 3: bạn nên tìm hiểu ddd, các service nên chia theo domain, bounded context...
Một kiến thức nào muốn học đều cần thời gian , nhưng nếu học đúng nơi như video này chúng ta tiết kiệm được thời gian research và bắt tay vào luôn , Anh đưa tư duy vào để trình bày cực kỳ dể hiểu , súc tích. Thế thôi nhưng rất hiếm người làm được vậy.
Mình tin phần lớn các bạn xem vid này chưa từng làm việc với microservices trong thực tế nên khi nghe vid này cảm thấy rất thuyết phục. Nhưng nếu microservices thực sự thần thánh và dễ kiểm soát như vậy thì có lẽ công ty nào cũng đã triển khai nó rồi. Đừng thần thánh hoá công nghệ mà hãy tập trung vào giải quyết vấn đề, monolithic cũng có những ưu điểm của nó, microservices cũng vậy. Chọn một kiến trúc phù hợp cho business chứ không phải cứ lúc nào cũng microservices.
đối dự án lượng dữ liệu lớn, hay số lượng người dùng nhiều, hay những dự án sử lý nặng dùng cách chia để trị.
còn các dự án nhỏ làm cho nó phức tạp😂😂😂
phần lớn lập trình viên sài rồi nhưng không biết là mình đang sài nó.
như opentid hay payment, hay server web, server database.... hay các dự án chạy trên vài server, pc... đây hay làm các dự án view trên server, process trên 1 server khác.
tùy vào dự án, trước làm mấy dự án web craw. mình sài cách này. vì phần craw nặng làm ảnh hưởng đến tốc dộ truy cập của website nên tách ra thành server riêng chạy.😂😂😂
Bạn nói chuẩn. Tùy dự án và tùy quy mô doanh nghiệp cũng như chi phí mà ta chọn microservices or monolithic. Nếu chỉ là 1 ứng dụng nhỏ thì làm monolithic cho mau ....
Thật tình cờ em cần tìm hiểu về docker thì youtube gợi ý video của anh, em thật sự ấn tượng cách anh nói, không lan man, minh họa dễ hiểu, giọng ấm và trầm. Rất mong anh sẽ tiếp tục ra video dài dài.Cảm ơn anh rất nhiều.
Từ nội dung cho tới cách trình bày, giọng đọc, làm video... rất tuyệt vời khó có thể tìm thấy ở nơi nào khác❤
Hay quá , đây như một cái road map để học tiếp nè
Thank bác nhiều nhen. Mình làm D.A mà ngồi trog phòng cùng với team Infra nên ăn suốt ngày nghe mấy thuật ngữ này hoài nhưg chả hiểu gì. Giờ thì có thể chém gió chút dc rùi
u là trời, đây là 1 kênh caseStudy mà em đang rất cần, video rất hay và dễ hiểu. mong anh ra nhiều video hơn
Nội dung rất chỉnh chu và bổ ích, truyền đạt rất dễ tiếp thu, mong kênh phát triển hơn nữa
Khi nghe bạn giải thích mình thấy rất cuốn hút và hay, bạn nên ra nhiều thêm video nữa, rất bổ ích
video rất dễ hiểu đối với cả những người mới .mong b mạnh khoẻ để ra nhiều content chất lượng
hay quá anh ui, nói về tech mà nghe cuốn quá
video chất lượng và bổ ích, +1 respect
Video rất hay, dễ hiểu, nhiều thông tin hữu ích. Mong anh ra nhiều video hơn ah !!!
Anh truyền đạt rất dễ hiểu, cảm ơn anh nhiều ạ
Respect bạn vì clip rất hay, animation cũng rất hợp nhãn.
Nó còn hoàn hảo hơn nếu chúng ta có thể phát âm từ vựng chuẩn xác nữa. Bạn có thể tra trên google các từ như service, python... xem nó đọc như thế nào rồi phát âm lại cho đúng nhé😄
Rất hay, sẽ tiếp tục ủng hộ, hi vọng a sẽ ra thêm nhiều nội dung về devops
anh nói và làm video vui tính dễ hiểu quá, cảm ơn anh nhé
Nội dung rất hay và hữu ích, ngắn gọn, minh hoạ dễ hiểu, giọng đọc rất tốt. Hi vọng sắp tới anh sẽ tiếp tục chia sẻ các content về microservice, load balancing, ... 🥰
Video rất dễ hiểu mong anh ra nhiều video hơn !!!
nice video, keep it up bro
Nice!, Video diễn giải rất tiệm cận. Hóng AWS và Monitor hữu ích từ bro.
Mình là software dev cũng lâu , video rất hay và dể hiểu nhưng mà nên thêm chi tiết vào 1 tí để các bạn mới học sẽ dể nắm bắt hơn .
Nhất là phần demo bạn đã bỏ qua bước giải thích service discovery trong các service của bạn nhảy thẳng vô luôn , đương nhiên tất cả mấy cái đó thằng K8s hỗ trợ hết rùi nhưng cũng nên giải thích á
Đương nhiên đây là vấn đề của DevOPS , nhưng mà Dev BE cũng phải biết á .
Đó là chưa nói đến việc bạn bỏ qua bước Database và bước Message Queue ( Hầu như microservice thì 2 thằng này là quan trọng cực kỳ ) . bất kỳ hệ thống nào .
Việc setup Kafka hay RabbitMQ hay bất kỳ 1 queue sever trung gian nào cũng là 1 quá trình gian khổ kkk
Trong video mình có nói là microservices và K8s còn rất nhiều thứ để nói. Nhưng vì đây là video giới thiệu nên mình k muốn cho quá nhiều thông tin vì sẽ thành lan man. Nhưng cũng cảm ơn bạn vì nhận xét rất có tâm. Những video sau mình sẽ nói sâu hơn. Chờ nhé!!!
@@khalid_dinh à quên mất bạn là devOPS hay full stack hay như nào nhỉ .
Do mình cũng dev Backend rùi biết thêm tí bên devOPS để dể triển khai thôi chứ cũng không phải chuyên gia vận hành kkk
@@Namlepy mình Devops nhé
xem đúng 2 video là phải đăng kí ngay, dễ hiểu ghê. Mong anh ra thêm nhiều video nữa
Cảm ơn bạn đã chia sẻ. 1 Like
Anh làm video về 1 sản phẩm thực tế triện khai như nào, xây dựng database ra sao vd cần 1 databse để read và 1 cái để write em thường nghe vậy, thiết kế code Vd design parttern , dùng thêm công cụ gì vd redis hay dùng nhiều cái gì đó. và cảm ơn anh vì video trên
Tuyệt vời anh ơi, mong anh ra khóa học được không em chờ mãi rồi
Best video. Very useful and informative.
Thank you brother
Bạn giải thích rất dễ hiểu với hình minh hoạt rõ ràng và vui. Mong bạn làm thêm về Data Mesh và Kafka
Clip rất hay, thanks bro!
Clip rất bổ ích, tinh gọn và chuyên nghiệp. Cảm ơn anh
hóng bác public repo để mn cùng học hỏi
thề, coi video ông anh cuốn vl, dễ hiểu mà lại còn vui
Video qua hay a ạ 🎉
Video tiếp theo làm về Kubernetes Vs. Docker Vs. OpenShift nha anh
Dạ hay quá anh 😊
anh truyền đạt kiến thức quá dễ hiểu, ra nhiều video nữa nhé anh
Video rất hay, dễ hiểu, nhiều thông tin hữu ích. Mong anh ra nhiều video hơn
bạn làm video rất dễ hiểu và súc tích, mong là bạn sẽ ra video hand-on thêm :D
hóng video hướng dẫn setup ci/cd của anh ạ
your voice is really nice, bro
thề nghe ông này nói chuyện cuốn v chứ ko buồn ngủ :v
Quá hay
Bạn có thể thêm phần source code hoặc ref phần cuối video được k ạ? video rất dễ hiểu và trực quan, thanks bro
Em chào anh, biết kênh anh qua các video trước có thấy anh nói kênh anh làm về python, nên e rất mong anh sẽ sớm có chuỗi video về chủ đề django ạ. Django tuy có nhiều ưu điểm nhưng em thấy đang ít công ty tuyển fresher, thêm vào đó là khóa học Django bằng tiếng Việt em theo trên UA-cam của em thấy nó khác ngoài thực tế rất nhiều, điển hình là việc cập nhật dữ liệu ạ. Không mong anh có thể làm một khóc học chi tiết mà chỉ mong có một video đưa ra được một roadmap đầy đủ về Django là cũng tuyệt vời rồi ạ. Cám ơn anh
Hay quá
Anh làm video về Cloud Computing đị ạ
mở lớp dạy luôn đi anh ơi. nghe như này chưa đã lắm
Quá hay ạ. Bạn có thể làm 1 tutorial để setup hệ thống k8s đc k ạ
Video rất hay ạ
vô mấy cty theo công nghệ cũ chán vãi . gọi là block Tech lun, mãi làm toàn ba cái công nghệ nhà mình , cái source thì qua 15 năm cả trăm thằng viết vô .noi chứ mĩnh vấn thích làm cty Product hơn.
Anh trông chất chơi người dơi người sắt người nhện thế này mà để kiểu tóc brimlock nữa thì không khác gì rrrrapper luôn
:)))
Làm thêm series về design system được không broooooo
video rất hay, rõ ràng, và đẹp. Bạn có thể share cho mình bạn lấy các clip bên ngoài để chèn vào video ở source nào vậy ạ? cảm ơn bạn
hi, mình có 1 câu hỏi là sự khác biệt giữa microservice và multi-moonlithic gì ạ?
Nếu mình gặp 1 ứng dụng đang sử dụng mô hình MVC có rất nhiều service module lớn, làm sao với 1 team 4 người mình có thể cover refactor lại toàn bộ thành Microservices? mình cần làm những bước nào và mất bao lâu? nhờ Khalid Dinh gợi ý giúp mình với
Hello a iu ❤❤❤
Tiết kiệm được mấy ngày nếu tự tìm hiểu, thanks a
nghe hay thật
Điểm yếu là khó tracing lỗi. Nếu cần xử lý transaction trong db lại càng khó nữa. Thêm nữa nếu kafka mà chết thì coi như toàm bộ chết theo luôn.
am on anh
anh có thể làm nội dung về xử lý load balancer nginx bằng nodejs được không ạ
mong bạn làm về kafka
nice
Thank you
Coi video anh không hiểu sao cứ bị cuốn cuốn kiểu gì ấy.
Sẵn tiện cho em hỏi là: Nếu chỉ sử dụng 1 máy chủ nhưng dùng docker để chia ra các service trong máy chủ đó thì có được xem là microservices không anh? Hay phải là nhiều server triển khai các services này thì mới coi là microservices?
triển khai lên container hay lên server nó là cách deploy thôi em. Microservices là về cách thiết kế kiến trúc của phần mềm. Nên ở câu hỏi của e thì về mặt lý thuyết thì vẫn gọi là microservices. Nhưng thực tế thì không ai chỉ dùng 1 server vì không có lợi về tính HA (High availability)
anh có thể để link repo để em có thể tham khảo và triển khai thử ạ.
video của anh rất hay, mỗi tội phần demo anh làm nhanh quá em theo hơi ngộp
ừm, để mình lưu ý hơn
Làm cho tới đi ông. Mỗi service cần có DB riêng và cách thức chúng giao tiếp và trao đổi dữ liệu với nhau như thế nào
Những nội dung sâu hơn mình để cho những video sau nhé
Có cần thiết phải tách db ra k ạ, nếu mình làm chung 1 con db thì sao ạ
@@neko.1997 nếu dùng chung db thì sẽ mất đi nhiều các ưu điểm của ms, VD scaling, independency,... Nhưng vẫn có trường hợp dùng.
cho mình hỏi 1 hệ thống đc xem là monolithic phụ thuộc vào gì, ví dụ mình có nhiều service viết bằng nhiều ngôn ngữ khác nhau nhưng tất cả đều sài chung 1 database, vì khái niệm cơ bản của microservice mà mình hiểu thì mỗi 1 service sẽ có database riêng. vậy hệ thống này có đc xem là monolithic ko ?
monolithic thì không chia services, khi build thì chỉ tạo ra 1 artifact (VD 1 file .jar), nó cũng chỉ có 1 database. Microservices thì ngược lại. Về việc microservices có thể chỉ dùng 1 db hay k thì thực tế là vẫn có hệ thống như vậy. Tuy nhiên thiết kế như vậy phải bỏ đi các ưu điểm của microservices cho khối db: Scaling, High Availability, ... Dĩ nhiên việc thiết kế db trong microservices cũng phức tạp và khó hơn. Nó là bài toán cân đối lợi ích
Sieu thật
😃🥰🥰🥰
sao kênh a ít video thế ạ
Cho em hỏi vậy cdn có được xem là một phần của microservices không ạ
Không hẳn, vì nhiều hệ thống microservices mình biết k có CDN.
+1 respect, bro
A cho e hỏi FE có tách luôn theo từng service ko hay FE là 1 mono gọi đến BE theo kiến trúc ms ạ
cái này tùy dự án nhé. Có cái thì là 1 khối FE riêng, gọi đến BE. Có cái thì bản thân 1 số services ở BE sẽ có FE riêng của nó
@@khalid_dinh Clear!! Tks u
Cho em hiện tại công ty em đang làm monolithic + nginx và test đổ tải khoảng 2-4 nghìn user sử dụng thì api bắt đầu có dấu hiện lỗi. Nếu chuyển qua microservice thì ví dụ việc call api 1 sản phẩm rồi sản phẩm đấy lại call 5 api đánh giá sản phẩm như ví dụ trên video, nó có khả năng bị quá tải nếu 1000 user call api sản phẩm (call 5000 api đánh giá sản phẩm) không ạ? Em là người mới nên mong được mọi người giải đáp ạ ^^
Vấn đề là cần biết tại sao nó lỗi. Nếu lỗi do thiếu tài nguyên thì cần tìm xem điểm nào trong chuỗi call API đang bị quá tải. Hay services nào đang được call nhiều. Rồi cấp thêm tài nguyên cho service đó bằng việc scaling. Đây là phương pháp chung cho cả monolithic và microservices. Microservices thì nó có lợi thế về monitoring + scaling + HA hơn nên việc phát hiện nút thắt, alert, scaling / modify cũng sẽ tiện hơn. Nhưng không có gì đảm bảo 100% khi chuyển sang microservices sẽ không bị quá tải. Quan trọng nhất vẫn là phát hiện đâu là nguyên nhân dẫn đến failure
các service có dùng chung database không nhỉ, hay họ cũng tách database ra
thường thì phải tách ra
@@khalid_dinh vậy 1 service độc lập 1 database đúng không bạn. vậy chẳng khác gì 1 service là 1 sản phẩm product rồi nhỉ
theo anh thì một kiến trúc như chia thành 2 khối FE và BE riêng biệt thì nó có phải là 1 biến thể của 3 present layer không ạ ? Thanks anh
Việc khối FE và BE riêng biệt, hầu như k phải là cách nhận biết 3 tiers hay microservices. Sự khác biệt lớn nằm ở các services và database của service ở BE có tách nhau k. Nếu có thì là MS, nếu k thì là monolithic. Còn hầu như mọi mô hình thì FE và BE vẫn được tách riêng.
@@khalid_dinh "chia" ở đây được hiểu theo nghĩa nào anh nhỉ, vì có vài architecture vẫn có thể gộp được cả FE và BE thành 1 block sau đó đẩy lên cloud service
@@brolynguyen3430 chia nghĩa là tách từ codebase, cách giao tiếp giữa các services, cách triển khai các service đó lên các server, cách tách database cho từng service. Nếu đáp ứng đủ thì là microservices. Còn k thì có thể là monolithic hoặc các kiểu trúc khác
Cho mình hỏi Chrome dùng monolytic nên mới ngốn ram phải không? Kaka
không hẳn vậy
E xin link github vs ạ
đỉnh
Fun fact: một hệ thống lớn như Stack Overflow lại sử dụng monolithic
Dev còn trụ được thì monolithic hay ms không còn quan trọng 🤣🤣🤣 Chưa chắc chuyển đổi sang ms đã ngon, quan trọng là phải phù hợp với tình hình và năng lực team nữa
đúng vậy
anh khóa bn FPT z ạ? pro wa T_T