Category: Technology

Categories
Technology

Vũ trụ Nextjs và Headless CMS

Sau nhiều ngày chờ đợi để xem NextJS có ra bản 13.5 hay không thì cũng không chịu được nữa (nằm ở v13.4 đã gần 3 tháng) và đành khởi công dự án xây dựng Public CMS Framework (hay nói kiểu nhà quê là làm cái website) với phiên bản NextJS 13.4.12.

Server Side Rendering (SSR) với PHP

Ở #Cropcom, mỗi một Public CMS Framework được xây dựng thì xác định tối thiểu phải 5 năm sau mới thay đổi công nghệ nên việc lựa chọn công nghệ nền ban đầu ảnh hưởng rất lớn đến trải nghiệm phát triển tính năng của team, cũng như phải “chịu đựng” trong quá trình xây dựng tính năng nếu lỡ nó lạc hậu hoặc team đó bỏ rơi không phát triển tiếp công nghệ nền.

Nếu bạn quan tâm thì Public CMS Framework gần nhất của công ty do Tuấn xây dựng là dựa trên PHP 7, sử dụng một phần của Symfony HTTPFoundation để xây dựng core, sử dụng Smarty cho tầng View (HTML, CSS..), còn layer Model & Controller thì kết nối đến hệ thống microservice theo cơ chế Headless CMS. Public CMS này thực ra hiện tại vẫn ổn vì nó tương thích hoàn toàn với khả năng Server Side Rendering (SSR) để tận dụng tối đa khả năng onsite SEO.

NextJS cho SSR & CSR trong tương lai

Hướng cũ này có một bất lợi duy nhất là, sẽ khó khăn nếu tiếp cận xây dựng các tính năng không cần SEO (sau màn hình đăng nhập) như thông tin tài khoản, các tính năng sau khi đăng nhập (submit này nọ, tương tác với thành viên khác…). Lỡ theo kiến trúc này nên phần lớn các tính năng đòi hỏi thuần Client Side Rendering (CSR) toàn phải xài jQuery và code chay, rất khó mở rộng theo nhánh này. Mà ngày nay, làm gì có website nào chỉ thuẩn SEO content, nếu vậy xài WordPress cho rồi, viết framework đồ chi.

Nếu muốn viết lại Framework mới cho Public CMS thì phải giải quyết được 2 bài toán là cần có SSR, hỗ trợ được các công nghệ CSR như Reactjs…để vừa đạt hiệu quả làm SEO, vừa hỗ trợ team dev phát triển tính năng một cách hiệu quả, nhanh chóng. Thế là đến với NextJS. Hiện tại sau hơn 4 năm chạy với Nextjs (từ nextjs 8.x đến nay thì phiên bản 13.4 được coi là siêu ổn để giải quyết 2 vấn đề lớn mà Tuấn cần giải quyết cho Public CMS của mình.

Lựa chọn UI Component Library

Tuy nhiên, sau khi trào lưu di dời sang Nextjs thì sẽ phát sinh 1 vấn đề khác là không có một bộ Component UI Library hoàn hảo. Và vấn đề này luôn là mối quan ngại khi xây dựng CMS với Nextjs bởi chưa có “cái nào” mà mình đánh giá là xài được. Radix UI thì có vẻ phức tạp, ngôi sao mới nổi Shadcn thì tạo ra các giao diện không mấy thân thiện với người dùng bình thường nên chủ yếu shadcn để xây các sản phẩm hơi hướng tinh giản và tech savy. Chưa kể nhiều UI Lib không tương thích với React Server Component.

Dường như vũ trụ Nextjs đã lắng nghe, và sau 1 ngày xây dựng thì dự án NextUI (không liên quan đến Vercel) hôm qua đã ra mắt phiên bản 2.0 với RẤT nhiều cải tiến mà sẽ dùng tốt cho NextJS 13 (dùng App Router). Việc thấy được sự ra mắt của NextUI 2.0 chính là cảm hứng cho mình chia sẻ bài viết này cũng như mọi người có thể hình dung xây dựng một Public CMS cần có nhiều yếu tố cân nhắc vì tính dài hạn và hướng người dùng (UX) & hướng dev (DX).

NextUI Website: https://nextui.org/

Trong tương lai nếu có lib nào xịn hơn thì sẽ xem xét và cân nhắc, nhưng cho đến hôm nay thì mình thấy NextUI là chân ái và sẽ apply cùng với TailwindCSS cho toàn bộ các design của CMS.

Categories
DevOps Technology

CHỌN CX HAY DX?

Dạo gần đây trên twitter có rất nhiều chỉ trích từ cộng đồng làm frontend về việc bản #Nextjs 13.4 cho tới 13.6 có trải nghiệm compile ở máy rất tệ khi sử dụng kiến trúc mới là App Router. Thời gian mỗi lần hot reload tính bằng giây và bản thân Tuấn đang phát triển cho hệ thống IDP của #cropany cũng thấy trải nghiệm tương tự, gần đây mỗi lần nhấn lưu là banh xác, chờ vài giây và compile vài ngàn module.

Việc này ảnh hưởng lớn đến #DX – hay gọi dễ hiểu là Trải nghiệm của lập trình viên (Developer Experience), cái được cộng đồng đánh giá công ty Vercel (hay dự án Nextjs) là một công ty có DX rất tốt, riêng mình nói về vụ DX thì Vercel là dẫn đầu thị trường thì nay lại bị chê bai rất nhiều.

Tuy nhiên, giá trị của kiến trúc App Router từ bản Nextjs 13.4 là không thể chối từ, nó đem lại trải nghiệm tốt hơn về thiết kế UI, Render flow (page, layout, template, server component, server action…) và cải thiện SEO ở mức tốt nhất cho các dự án CMS/Ecommerce. Đây cũng là lý do chính mà cả bộ sậu Vercel đầu tư rất nhiều vào kiến trúc App Router (thư mục “app”) để thay thế cho kiến trúc thư mục “pages” cũ. Những lợi ích này có giá trị rất lớn cho #CX – hay gọi dễ hiểu là Trải nghiệm của khách hàng (Customer Experience) 👍.

Các cuộc tranh cãi nổ ra kiểu nếu DX của App Router còn tệ hại như vậy thì chúng tôi sẽ bỏ đi, sẽ Vite + ReactJs, sẽ Angular, sẽ Gatsby 🤭…mà hoàn toàn phủ nhận giá trị của CX mà Nextjs mang lại.

Lịch sử đã cho thấy, chúng ta (developer) sẽ sẵn sàng đánh đổi 1 chút DX của mình để khách hàng được trải nghiệm tốt nhất. Chúng ta đã từng có giai đoạn dành cả tiếng đồng hồ để compile một phần mềm trong mỗi lần thử, dành cả ngày để render cái scene 3D cho đẹp hơn xí,… mà giờ có vài giây cũng kêu ca. Tuy nhiên, nếu sự chờ đợi dành cho quá trình phát triển để đem lại trải nghiệm cho khách hàng (CX) tốt hơn thì hoàn toàn xứng đáng. Vì trải nghiệm khách hàng khi sử dụng website tốt sẽ đem lại tiền cho doanh nghiệp.

Nói đi cũng phải nói lại, nếu DX của hệ thống tệ và đối thủ làm tốt hơn thì cộng đồng có thể quay lưng (như cách chúng ta đã quay lưng với nhiều thứ để đến với Nextjs). Hoặc nếu trong một dự án mà DX tệ thì sẽ ảnh hưởng không tốt đến nguồn lực dev của công ty. Mọi người sẽ tiếp cận dự án khó hơn, phát triển tính năng lâu hơn, chỉnh sửa, nâng cấp cũng vất vả…

Và sáng nay thật nhanh chóng, NextJs đã ra bản 13.4.8 với rất nhiều cải thiện để tối ưu cho DX sau rất nhiều càm ràm (và đòi bỏ đi) trên mạng. Quả thực, đi theo Nextjs từ bản 8.x tới giờ thì Nextjs không bao giờ làm ta thất vọng và phải nói trải nghiệm DX và CX từ Nextjs luôn làm ta ngạc nhiên và xứng đáng đầu tư toàn bộ stack ở cms/ecommerce đi theo Nextjs. Và việc release này cũng làm cảm hứng cho bài chia sẻ này.

Categories
Technology

Học Đại học CNTT nào?

Cách đây vài ngày có đọc một trao đổi trên Reddit về việc một OP hỏi là nên chọn học CNTT ở đại học Tôn Đức Thắng hay đại học FPT. Có khá nhiều ý kiến, chửi OP ngu có, chửi mấy thằng chửi người ta ngu cũng có và cũng có mấy ý khá thô nhưng thật đó là học trường nào ra cũng như nhau vì cũng không phải trường top và cầm tấm bằng tốt nghiệp của 1 trong 2 trường này là same same.

Tất nhiên sẽ có nhiều quan điểm bên ngoài là thời nào rồi mà còn phân biệt bằng đại học, miễn ra làm được việc là được, không nên kì thị blah blah…Vậy thì quý vị hãy nhìn xung quanh để xem vì sao các trường top được tranh giành ứng tuyển, những quản lý cấp cao hầu hết đều nằm ở trường top, hoặc mức lương trung bình của các bạn tốt nghiệp trường top sẽ cao hơn các bạn tốt nghiệp trường non-top.

Nhìn bề ngoài thì có vẻ kì thị, nhưng thực ra vấn đề lớn tạo nên điểm khác biệt ở hai môi trường này là “Bạn có gì trước khi vào trường top” và “Bạn sẽ có gì sau khi ra trường top”. Nếu xoay quanh 2 câu hỏi này thì sẽ dễ hình dung hơn vì sao có sự chênh lệch và phân biệt đối xử này từ thị trường tuyển dụng & việc làm IT.

Để vào trường top các bạn ít ra phải là một tay đáng gờm (bên cạnh sự may mắn, mấy ông rớt hay nói mấy ông đậu ăn hên) nên việc bạn học ở đâu không quan trọng (tất nhiên bạn sẽ chọn học trường top). Và với trí não (hoặc bà đãi) như vậy thì việc sau này đi làm gặp nhiều thuận lợi hơn là điều dễ đoán.

Tiếp đến, học trong trường top theo mình thấy được nhà trường đào tạo các môn ban đầu nhìn vào hoặc từ bên ngoài nhìn vào tưởng chừng như nhảm nhí, dư thừa nhưng thật ra càng đi làm mình càng thấy cực kì hay và thấy may mắn nhờ những môn học đó gieo vào đầu mình những hạt giống kiến thức nền tảng.

Ví dụ Tứng học khoa CNTT ở trường KHTN HCM (nghe nói trường này cũng đã từng đứng top), những môn mà lúc học thấy khá vô nghĩa như thời này mà còn học Assembly để làm gì, rồi còn học thiết kế mạch logic, toán rời rạc, mạng máy tính cơ bản, blah blah…Và được ca tụng nhất là môn Triết học. Riêng về cái triết học thì lúc học mình khá hứng thú tới khoảng 20-30% gì đó trong thời gian học (còn lại chủ yếu ngủ hoặc trốn) nhưng những bài học về triết học giờ ngẫm lại có ý nghĩa, ví dụ “Biến đổi về lượng dẫn đến biến đổi về chất”, nghe nhồi sọ nhưng thật ra nếu bạn làm ở ngành thiết kế hệ thống, với lượng truy cập ngày một lớn (lượng) thì bạn không thể dùng giải pháp hiện có mà phải thay đổi giải pháp (chất) để thích nghi, đó chỉ là một ví dụ nhỏ của việc học…triết học.

Do đó, nếu lỡ không được học ở một trường giúp tiếp cận các nền tảng công nghệ ở cấp độ cơ bản thì bạn có thể tự trang bị các kiến thức này. Việc tự trang bị kiến thức nền sẽ giúp bạn không cần bằng đại học trường top vẫn cạnh tranh với các ứng viên trường top, hay bà con thường gọi là “cần cù bù thông minh”.

Chỉ còn vài ngày nữa là đến kì thi, hy vọng các sĩ tử đạt được trường tốt mà mình ngắm.

Fighting!!!!

Categories
Review sách software Tech Startup Technology

Review sách “Product-Led Growth” của Wes Bush

Hôm nay review đến mọi người cuốn sách tiếng Anh mà đọc không rời mắt và hoàn thành sau một ngày chỉ với vài tiếng và có thể nói đọc nhanh hơn cả tiếng Việt. Bởi tính chất hấp dẫn và hữu ích của sách này nên dành hẳn 2 tiếng để làm sketch note và chia sẻ với mọi người để cùng tham khảo cũng như giúp các bạn dễ dàng quyết định mua sách này. Đó là cuốn “Product-Led Growth: How to Build a Product That Sells Itself” của Wes Bush.

Sách này gồm 3 phần và phần nào cũng cực kỳ hấp dẫn. Phần đầu nói về việc đánh giá và so sánh giữa công ty product-led và sales-led để giúp bạn đưa ra quyết định tiếp cận phù hợp với mô hình tổ chức cũng như đặc thù sản phẩm và thị trường. Phần tiếp theo nói về phương pháp tiếp cận khách hàng và phần cuối là phương pháp tối ưu hệ thống bán hàng, marketing.

Nếu bạn nào đang hoặc sắp tham gia lĩnh vực cung cấp phần mềm, đặc biệt là Saas như Tuấn thì sẽ không nên bỏ qua cuốn sách này vì có rất nhiều thông tin cực kỳ bổ ích. Từ lên chiến lược phát triển sản phẩm, chiến lược giá cũng như chiến lược marketing để mang lại khách hàng, doanh thu và lợi nhuận cho công ty.

Bên dưới là ghi chú cho từng phần từ sách, và mỗi chương trong sách cũng sẽ được chụp cận cảnh để giúp bạn thấy rõ hơn các nội dung chi chú của Tuấn. Xin thứ lỗi nếu chữ viết không rõ, tuy nhiên, nếu thấy nội dung hay thì bạn có thể mua để ủng hộ tác giá, sách có rất nhiều ví dụ và nội dung hay mà phần ghi chú mình chia sẻ trên đây không đề cập như các chương liên quan đến những sai lầm mắc phải khi cải tiến..

Ghi chú về phần 1

– So sánh mô hình giữa chiến lược sales-led và product-led để cho thấy hai cách tiếp cận khác nhau của việc phát triển sản phẩm.

Sanh sánh 2 mô hình sales-led và product-led và vì sao trong một công ty theo product-led thì các bộ phận đều hướng tới sản phẩm (product).

Dựa vào đặc thù sản phẩm và mô hình kinh doanh mà có các chiến thuật tiếp thị khác nhau để đem lại lợi thế cạnh tranh.

Hai hướng tiếp cận bán hàng khác nhau đó là Top-Down và Bottom-Up. Đối với doanh nghiệp làm Saas thì tốt nhất là theo chiến lược Bottom-Up bởi sẽ dễ dàng tiếp cận với tập khách hàng lớn, tiết kiệm chi phí và có thể dự đoán được doanh thu.

Ghi chú về phần 2

Mô hình UCD hướng đến khách hàng để đưa ra những thông tin phù hợp đến khách hàng.

Hiểu được các giá trị của sản phẩm bạn mang lại cho khách hàng.

Các chiến lược giá để giúp bạn đưa ra những bảng giá tính năng phù hợp nhất cho sản phẩm của mình và kèm theo nhiều phương pháp định lượng, định tính để giúp bạn ra bảng giá phù hợp nhất.

 

Phương pháp tối ưu để đem lại giá trị như đã truyền thông đến khách hàng.

Ghi chú về phần 3

Đây là phần được đánh giá là hay nhất và có nhiều kiến thức thực tế nhất để làm theo và áp dụng nhằm tối ưu hệ thống marketing và bán hàng.

Mô hình ICE để tìm ra những tính năng sẽ đem lại hiệu quả cao nhất giúp cải tiến sản phẩm.

Áp dụng The Bowling Alley Framework để tăng số lượng khách hàng.

Một số phương pháp để tối ưu doanh thu trung bình trên một người dùng (ARPU)

Phân loại churn và một số phương pháp giúp giảm tỷ lệ churn để hạn chế ảnh hưởng đến việc thất thoát doanh thu.

 

Đọc thêm về sách này tại https://www.amazon.com/Product-Led-Growth-Build-Product-Itself/dp/1798434520.

—

Hiện tại Tuấn vẫn luôn tìm kiếm những bạn có kinh nghiệm trong lĩnh vực marketing và growth, đặc biệt cho các sản phẩm phần mềm Saas. Nếu bạn quan tâm có thể email tới [email protected] để trao đổi thêm nhé.

Categories
Review sách software Technology

Review sách “The Mythical Man-Month” của Frederick P. Brooks

Tuần này mình sẽ review một cuốn sách khá hay dành cho các project manager có tựa là “The Mythical Man-Month”. Cuốn sách này lần đầu xuất bản 1975, tính ra cũng được 45 năm. Tuy đã viết từ lâu như vậy nhưng hầu hết những kinh nghiệm, quan sát và kết luận vẫn còn đúng cho ngành phát triển phần mềm hiện nay.

Brooks là một cây đa cây đề trong ngành phần mềm và thời điểm viết sách này (1975) là ông đang quản lý team phần mềm tại IBM. Cá nhân mình lập trình hơn 15 năm và quản lý nhiều dự án thì thấy những tư tưởng của tác giả đến nay vẫn dùng được. Sách viết từ 1975 nên tiếng Anh thời đó đọc tra từ điển cũng đuối vì có nhiều từ, mẫu câu đã cũ hoặc khá hàn lâm, đọc cũng nhức não mới hiểu nổi ý nghĩa.

Sách gồm 17 chương, trong đó có 4 chương mới được viết thêm vào 1995 nhân kỷ niệm 20 năm xuất bản. Sách này chình là khởi nguồn cho định luật Brooks cũng khá nổi tiếng là “Adding manpower to a late software project makes it later” (Đưa thêm người vào 1 dự án đang trễ, sẽ chỉ khiến nó càng trễ hơn).

Sách bao gồm những bài luận ngắn, riêng lẻ về các đề tài xoay quanh việc quản lý dự án phần mềm như về tài nguyên hệ thống, phần cứng, đội nhóm, nhân sự, dự án, tài liệu nội bộ, manual cho người dùng, sự thay đổi trong cấu trúc tổ chức, cũng như những khó khăn trong xây dựng phần mềm mà sẽ không có phương pháp triệt để nào giải quyết dứt điểm.

Chương mình thích hơn hết là Chương 2 (The Mythical Man-Month, cũng là tựa sách luôn) và chương 16 (No Silver Bullet – Essence and Accident in Software Engineering). Chương 2 là khởi nguồn cho định lý Brooks, liên quan đến việc phân tích sự liên hệ giữa nhân sự và thời gian (Man-month) và chỉ ra những trường hợp nào thì việc tăng người mới hiệu quả và cũng giải thích tại sao không hiệu quả trong những trường hợp khác. Chương 16 bàn về khó khăn khi triển khai cũng đưa ra nhiều góc nhìn và quan điểm khiến cho việc phát triển phần mềm sẽ luôn gặp khó khăn bởi có nhiều vấn đề là không thể thay đổi hay có giải pháp tối ưu để giải quyết.

Ngoài hai chương này ra, thì các chương khác bàn về documentation, manual cũng rất hay. Có hai khái niệm khác được đề cập và đến nay thấy hữu ích là “Conceptual Integrity” (yêu cầu cho thiết kế hệ thống) và “Second-System Effect” (các bạn startup sẽ thấy chương này hữu dụng vì nó chỉ ra hiệu ứng second-system, khiến cho việc bạn xây dựng những hệ thống quá phức tạp, ảnh hưởng đến thời gian release dự án bởi vì bạn…quá giỏi giang trước đó – thành công của First system).

Bên dưới là nội dung tóm lượt của Chapter 2 (The Mythical Man-Month) mình copy ra đây để các bạn lấy ý tưởng.

2. The Mythical Man-Month

2.1 More programming projects have gone awry for lack of calendar time than for all other causes combined.

2.2 Good cooking takes time; some tasks cannot be hurried without spoiling the result.

2.3 All programmers are optimists: “All will go well.”

2.4 Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation.

2.5 But our ideas themselves are faulty, so we have bugs.

2.6 Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.

2.7 Partitioning a task among multiple people occasions extra communication effort-training and intercommunication.

2.8 My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.

2.9 As a discipline, we lack estimating data.

2.10 Because we are uncertain about our scheduling estimates, we often lack the courage to defend them stubbornly against management and customer pressure.

2.11 Brooks’s Law: Adding manpower to a late software project makes it later.

2.12 Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.

Sách có thể mua trên Amazon. Chúc mọi người một tuần vui vẻ.

Categories
Technology

Xây dựng hệ thống Log cho Microservices

Hôm qua mình có làm speaker chia sẻ về kiến trúc hệ thống Log của Teamcrop.com, thấy nhiều bạn hưởng ứng và quan tâm quá nên mình khai trương blog năm mới bằng một bài viết ngắn nói về chủ đề này.

Xây dựng hệ thống log được đánh giá rất quan trọng, đặc biệt đối với các hệ thống đang trong giai đoạn tăng trưởng người dùng và mở rộng tính năng. Có nhiều hướng tiếp cận khác nhau để triển khai hệ thống log, từ việc sử dụng các dịch vụ Saas có sẵn, không cần cài đặt hay server gì như các hệ thống Loggly, DataDog, Papertrail…cho tới các open source như Graylog, ELK (ElasticSearch, Logstash, Kibana) Stack, Grafana…Tuy nhiên, do đặc thù của dữ liệu, số lượng log và tốc độ truy xuất mà Teamcrop buộc phải thiết kế một hệ thống log riêng để giải quyết các vấn đề về chi phí lưu trữ và vận hành.

Để xây dựng hoặc tìm hiểu một hệ thống Log, chúng ta cần thấy được các thành phần của hệ thống Logging bởi performance và tính tiện dụng đều dựa vào mô hình hệ thống Log. Mình tạm chia một hệ thống Log thành ba thành phần cơ bản là Collector, Storage và Dashboard.

  • Collector là phân hệ chịu trách nhiệm thu thập dữ liệu log từ các nguồn cung cấp (syslog, access log, error log, api request, sql query..)
  • Storage là thành phần sẽ lưu trữ dữ liệu log, có thể là tạm thời hoặc vĩnh viễn, ví dụ như RabbitMQ (tạm thời), File System (tạm thời), MySQL, Clickhouse…
  • Dashboard là thành phần sẽ truy xuất vào storage và hiển thị dữ liệu bao gồm data table, biểu đồ, dashboard…đến đối tượng cần coi log.

Để dễ dàng tiếp cận với các vấn đề của Log, trước tiên chúng ta cần phân loại log vì mỗi loại log sẽ có đặc tính khác nhau về số lượng cũng như cách truy xuất, sử dụng. Mình tạm phân loại Log thành 2 loại: Business và Operation Log.

Business Log

Business Log là những loại log giúp hỗ trợ các hoạt động và quyết định của doanh nghiệp. Như các Usage Log liên quan đến sử dụng các tính năng trên giao diện để bộ phận marketing, product dễ dàng ra quyết định liên quan đến kinh doanh và phát triển sản phẩm. Đối với loại log này thì hiện tại có ông trùm và được sử dụng khá nhiều là Google Analytics. Nếu cần open source thì có thể sử dụng Matomo (tiền thân là Piwik) để cài đặt trên server của bạn, tính năng của Matomo cũng gần như Google Analtyics.

Một loại Business Log khác mà mình đề cập trong phần chia sẻ là Critical Function Log dành cho những nghiệp vụ quan trọng, giúp đảm bảo an toàn cho hệ thống và khôi phục được trong trường hợp sự cố xảy ra và có thể tạo được dữ liệu. Log này quan trọng vì trong một kiến trúc Microservices thì có thể do cấu hình, cài đặt hoặc lỗi hệ thống khiến cho 1 service có thể bị cô lập và không gọi được các service khác trong quá trình thực thi. Ví dụ như tạo đơn hàng (service Đơn hàng) sẽ gọi các service như Sản phẩm, Tồn kho, Khách hàng, Thu chi…để hỗ trợ quá trình tạo đơn hàng. Nếu trong quá trình tạo đơn hàng mà toàn bộ các service khác không thể truy cập thì service Đơn hàng sẽ có một cơ chế an toàn riêng để đảm bảo dữ liệu request lên (raw POST data) được backup tạm thời phòng trường hợp cực hạn này. Số lượng tính năng áp dụng cơ chế log này là không lớn.

Loại log cuối cùng trong nhóm Business Log mà mình muốn đề cập là Auditing Log. Loại log này khá là quan trọng và nếu bạn đang phát triển các hệ thống Enterprise không thể bỏ qua. Auditing Log giúp doanh nghiệp có thể dễ dàng phát hiện các hoạt động bất thường, quan trọng (như xóa, import, export dữ liệu…) để kịp thời có hướng xử lý. Auditing Log còn có thể thiết kế như một hệ thống Change Log để lưu lại lịch sử thay đổi dữ liệu của 1 record (như đơn hàng, khách hàng…). Nếu có tìm hiểu về Microservices thì các bạn sẽ thấy cách thức lưu change log này của Auditing Log khá giống với pattern Event Sourcing (ES) trong mô hình CQRS/ES.

Trong hầu hết trường hợp thì chúng ta ít khi tập trung vào tự xây dựng business log bởi đối với loại này phải được phân tích kỹ và chỉ định cụ thể dịch vụ nào, tính năng nào cần được log (Auditting, Critical, Usage) để tiến hành lập trình nâng cấp.

Operation Log

Nhóm log thứ hai được đánh giá là có tác động to lớn đến quá trình tối ưu, cải tiến hệ thống là Operation Log. Một số loại log thuộc nhóm này bao gồm: Operating System, General Log, API Request, SQL Query và Distributed Tracing.

Operating System Log là nhóm log cơ bản giúp theo dõi và đánh giá tình hình chung của hệ thống như ổ cứng, memory, cpu, network IO…đối với nhóm log này thường đi kèm với hệ thống monitoring và bên Teamcrop sử dụng NodeQuery.com để theo dõi vì hệ thống NodeQuery khá tốt và đơn giản, kèm với giao diện dashboard rất dễ dùng và cơ chế alert hiệu quả. NodeQuery cũng được rất nhiều công ty trên thế giới sử dụng.

Loại log tiếp theo trong nhóm Operation Log là General Log, bao gồm những Log liên quan đến hoạt động của Nginx, PHP…và những custom log message do bạn ghi xuống trong quá trình vận hành hoặc debug hệ thống. Cùng với API Request Log, SQL Query Log thì mình tự xây dựng cơ chế log riêng bởi số lượng và tần suất log rất cao, việc sử dụng các hệ thống khác hoàn toàn không hiệu quả về hiệu suất và kinh tế.

API Request Log là loại log để theo dõi toàn bộ các request vào hệ thống Microservices. Giúp bộ phận lập trình biết được performance của các request như thời gian thực thi một tính năng (execution time) cũng như memory cấp phát cho các tính năng.

SQL Query Log cũng là loại log có mục đích khá giống với API Request Log, giúp lập trình viên và DB Admin có thể theo dõi được tình hình truy vấn database, câu truy vấn nào chưa tối ưu, table nào được truy cập nhiều, tình trạng tỷ lệ master/slave trong mô hình replicate có duy trì ở mức ổn định hay không…

Cuối cùng là một loại log cực kỳ cần thiết trong quá trình vận hành một hệ thống Microservices, đó là Distributed Tracing. Hầu hết các bạn khi chuyển sang kiến trúc Microservices, sẽ hay bị trình trạng service gọi lồng vào nhau, A –> B —> C —> D thì khi có một lỗi hoặc bottleneck nào đó ở một service bên trong (vd service C) thì rất khó phát hiện và debug bởi đặc thù phân tán của kiến trúc Microservices. Để giải quyết vấn đề này thì kỹ thuật Distributed Tracing sẽ giúp ích rất nhiều. Teamcrop sử dụng Zipkin Library PHP dùng để format dữ liệu theo đặc tả OpenTracing và backend sử dụng Jaeger (dự án Open source của Uber).

Đó là toàn bộ những chia sẻ của Tuấn tại buổi meetup đầu năm 2020 ngày 09/01/2020. Bên dưới là phần Slide trình bày (có cải tiến cho dễ hiểu hơn).


Dưới đây là schema của 3 table tương tứng với 3 loại log (General Log, API Request Log và SQL Query Log) được tạo trong database ClickHouse:

CREATE TABLE log_request (
  lr_date Date,
  lr_datetime DateTime,
  lr_hour UInt8,
  lr_minute UInt8,
  lr_service String,
  lr_method String,
  lr_controller String,
  lr_action String,
  lr_companyid UInt32,
  lr_userid UInt32,
  lr_status UInt16,
  lr_exectime Float32,
  lr_memory Float32,
  lr_ip String,
  lr_depth UInt8,
  lr_source String,
  lr_traceid String,
  lr_tracespanid String
) ENGINE = MergeTree(lr_date, (lr_datetime, lr_hour, lr_minute, lr_service, lr_method, lr_controller, lr_action, lr_companyid, lr_userid, lr_status, lr_exectime, lr_memory, lr_ip, lr_depth, lr_source, lr_traceid, lr_tracespanid), 8192);;


CREATE TABLE log_sql (
  ls_date Date,
  ls_datetime DateTime,
  ls_hour UInt8,
  ls_minute UInt8,
  ls_hosttype String,
  ls_host String,
  ls_querytype String,
  ls_table String,
  ls_exectime Float32,
  ls_companyid UInt32,
  ls_userid UInt32,
  ls_traceid String,
  ls_tracespanid String
) ENGINE = MergeTree(ls_date, (ls_datetime, ls_hour, ls_minute, ls_hosttype, ls_host, ls_querytype, ls_table, ls_exectime, ls_companyid, ls_userid, ls_traceid, ls_tracespanid), 8192);


CREATE TABLE log_syslog (
  ls_date Date,
  ls_datetime DateTime,
  ls_hour UInt8,
  ls_minute UInt8,
  ls_message String,
  ls_tag String,
  ls_host String,
  ls_source String
) ENGINE = MergeTree(ls_date, (ls_datetime, ls_hour, ls_minute, ls_message, ls_tag, ls_host, ls_source), 8192);

P.S: Teamcrop.com là hệ thống phần mềm quản lý bán hàng và nhân sự, nếu bạn nào quan tâm thì có thể dùng thử và ủng hộ một startup hoàn toàn Việt Nam nhé. Nếu bạn nào hứng thú với PHP hoặc kiến trúc Microservices, thì có thể cùng tham gia xây dựng Teamcrop với Tuấn, mọi thông tin gửi vào email trong trang cuối của Slide ở trên nhé.

Categories
Technology

Lấy email từ bình luận của bài viết trong Facebook

Chào các bạn, số là hôm nay bữa giờ trong cái group Launch trên facebook có thấy 1 bài có 1 membẻ tặng phần mềm email marketing (miễn phí) cho các bạn bình luận. Có đến gần 500 comment chứa nội dung email nên thiết nghĩ đây là 1 kho báu cho những ai đang làm các tool email marketing, còn gì tuyệt vời hơn khi có gần 500 email khách hàng cực kỳ tiềm năng và sẵn sàng sử dụng. Mình nghĩ cũng có nhiều người như mình nhưng phải ngồi copy từng email ra thì thiệt là khổ, nay chia sẻ mọi người cách nhanh nhất (3 phút) để “copy” toàn bộ các email này.

Continue reading “Lấy email từ bình luận của bài viết trong Facebook”
Categories
DevOps Technology

Git submodule cho người bận rộn

Số là hôm nay vừa chuyển 2 repo framework và restful sdk của Teamcrop từ composer về submodule nên chia sẻ nhanh 1 số bước để sử dụng submodule cho repo của bạn. Một phần để lưu lại sau này dùng vì kiến thức rồi sẽ ra đi, chỉ có blog là ở lại và cũng chia sẻ cho bạn nào chưa biết.

Nói một cách ngắn gọn thì submodule giúp bạn mang 1 repo khác bỏ vào repo đang làm việc, giúp việc tái sử dụng code hiệu quả hơn. Ví dụ như đối với dự án Teamcrop là muốn nhúng core framework và restful sdk dùng cho tất cả microservices. Còn vì sao mình dùng submodule mà không dùng composer hoặc các hình thức khác thì mình thấy submodule khá phù hợp với mô hình private repository.

Continue reading “Git submodule cho người bận rộn”
Categories
Technology

Web Scalability 101: Database và Microservices

mysql-database

Cũng gần một tháng kể từ bài đầu tiên trong loạt bài vỡ lòng về web scalability. Hôm nay mình tiếp tục chia sẻ một vấn đề khác cần quan tâm nếu bạn muốn scale hệ thống web tốt hơn đó là scale hệ thống cơ sở dữ liệu (database) và vì sao kiến trúc Microservices lại tốt cho database của bạn và không được bỏ qua kiến trúc này.

Continue reading “Web Scalability 101: Database và Microservices”
Categories
Technology

Web Scalability 101: Biết giới hạn của hệ thống

scalability
Sau mấy tuần vật lộn với công việc sau Tết thì cũng có thời gian viết lách. Đây là bài viết về kỹ thuật đầu tiên của năm và là bài đầu tiên trong loạt bài chia sẻ về các chiến thuật scaling hệ thống web có tên là “Web scalability 101 (vỡ lòng)”.

Nếu quan tâm đến scale hệ thống, bạn có thể google những từ khóa liên quan đến scale, ngôn ngữ, công nghệ mà hệ thống bạn đang sử dụng, và phần lớn là các bài viết chỉ về các cài đặt, cấu hình cụ thể của một công nghệ nào đó như tùy chỉnh PHP thế nào, tùy chỉnh nginx, tùy chỉnh mysql ra sao…và có thể bạn sẽ lạc trong một mớ hỗn độn các kiến thức cấu hình này.

Continue reading “Web Scalability 101: Biết giới hạn của hệ thống”