“Những sản phẩm tuyệt vời có khi chỉ bắt đầu từ những ý tưởng nhỏ bé, bạn có dám thử bước ra khỏi vùng an toàn và thể hiện ý tưởng tuyệt vời của mình?”
Chuỗi Hackathon AngelHack đã chính thức có mặt tại Việt Nam, được biết đến như một sự kiện tranh tài Công nghệ mới quy mô toàn cầu đã có mặt trên 106 thành phố tại 65 quốc gia và tạo nên làn sóng khởi nghiệp cực kì mạnh mẽ với hơn 115 công ty khởi nghiệp ra mắt trên toàn thế giới. AngelHack đã trở thành một điểm hẹn của không chỉ DEVELOPER, DESIGNER mà còn là của các DOANH NGHIỆP để cùng nhau tạo nên những đột phá đổi mới sáng tạo thay đổi cuộc chơi của toàn thị trường.
Năm 2019 này, AngelHack sẽ đồng hành tổ chức cùng TopDev – cộng đồng IT & Programming lớn nhất Việt Nam, đã chính thức chọn 2 thành phố – Hà Nội và Hồ Chí Minh làm nơi quy tụ những nhà tiên phong dám thay đổi & dám thách thức bản thân ra khỏi giới hạn an toàn.
Không chỉ được hoàn thiện và khai phá hết các tiềm năng trong project của bạn, bạn còn có cơ hội gặp gỡ trực tiếp những nhà tiên phong, các chuyên gia công nghệ hàng đầu tại các startup thành công – những câu chuyện, kinh nghiệm xương máu và góc nhìn của họ chắc chắn sẽ giúp ích rất nhiều cho sự nghiệp và hướng đi sắp tới của bạn.
Những thử thách “khủng” thì không thể thiếu những phần thưởng tương xứng cho những ai dám chinh phục:
Tổng giá trị giải thưởng cho người thắng cuộc gồm 3500$ hiện kim và lên đến 16,000$ hiện vật cho đội thắng cuộc
Đội thắng cuộc sẽ được đặc cách tiến vào chương trình HACKcelerator trị giá 25,000$
Nâng cấp chính mình với đội ngũ các chuyên gia, dàn mentor và ban giám khảo “lão làng” trong ngành mà bạn dõi theo và học hỏi
Khám phá cơ hội phát triển nghề nghiệp tại các Công ty – các Nhà tuyển dụng hàng đầu Ngành mà bạn hằng ao ước
Các team ấn tượng sẽ có cơ hội được đặt cách tham gia vào các Vườn ươm khởi nghiệp cực “hot” trong nước như Start-up Studio từ Sun*, VIISA, etc.
Và không thể bỏ qua, cơ hội học tập và trải nghiệm độc nhất và không bỏ lỡ cuộc vui cùng những người chung đam mê và mindset!
Kim chỉ nam xuyên suốt của Hackathon từ những ngày đầu tiên đó chính là: Ai cũng đều được chào đón. Những sản phẩm tuyệt vời đều bắt đầu từ những ý tưởng nhỏ bé và chúng tôi tin rằng những ý tưởng tuyệt vời thì cần được nói ra – với ai đó có nền tảng hoặc kinh nghiệm. Với mindset này, AngelHack đón nhận tất cả các công ty khởi nghiệp thành công, những nhà phát triển, doanh nhân và nhà thiết kế đam mê sáng tạo để tham gia vào chuyển động này bất kể trình độ kinh nghiệm hay vị trí địa lý nào.
Hơn 10,000 bạn trẻ đã tham gia và cùng chung tay tạo nên chuỗi series Hackathon hoành tráng nhất năm 2018. Đừng bỏ lỡ cơ hội này và trở thành một phần của AngelHack 2019!
Token-basedauthentication là phương thức xác thực bằng chuỗi má hóa. Một hệ thống sử dụng Token-based authentication cho phép người dùng nhập user/password để nhận về 1 chuỗi token. Chuỗi Token này được sử dụng để “xác minh” quyền truy cập vào tài nguyên mà không cần phải cung cấp lại username/password nữa.
Tiếp theo, chúng ta sẽ tìm hiểu về phương pháp sử dụng Token-based authentication bằng JWT (Json Web Token).
JWT – JSON Web Token là gì?
JSON Web Token là một chuỗi mã hóa mà nguồn gốc ban đầu là một chuỗi JSON. Chuỗi thông tin dạng JSON bằng phương pháp mã hóa nào đó, nó trở thành 1 chuỗi ký tự lộn xộn nhìn vào sẽ rất khó hiểu.
JSON Web Token (JWT) là 1 tiêu chuẩn mở (RFC 7519) định nghĩa cách thức truyền tin an toàn giữa các thành viên bằng 1 đối tượng JSON. Thông tin này có thể được xác thực và đánh dấu tin cậy nhờ vào “chữ ký” của nó. Phần chữ ký của JWT sẽ được mã hóa lại bằng HMAC hoặc RSA. (Nguồn: techmaster.vn)
Như vậy, Bảo mật JWT là phuơng pháp xác thực quyền truy cập (Authentication) bằng JSON Web Token.
Là nơi chứa các nội dung của thông tin (claim). Thông tin truyền đi có thể là mô tả của 1 thực thể (ví dụ như người dùng) hoặc cũng có thể là các thông tin bổ sung thêm cho phần Header. Chúng được chia làm 3 loại: reserved, public và private
Reserved: là những thông tin đã được quy định ở trong IANA JSON Web Token Claims registry. Những thông tin này không có cái nào là bắt buộc cả. Tuy nhiên tùy vào từng ưng dụng bạn implement mà hãy ràng buộc yêu cầu bắt buộc đối với những thông tin cần thiết
iss (issuer): tổ chức phát hành token (không bắt buộc)
sub (subject): chủ đề của token (không bắt buộc)
aud (audience): đối tượng sử dụng token (không bắt buộc)
exp (expired time): thời điểm token sẽ hết hạn (không bắt buộc)
nbf (not before time): token sẽ chưa hợp lệ trước thời điểm này
iat (issued at): thời điểm token được phát hành, tính theo UNIX time
jti: JWT ID
Public: Khóa có thể define tùy theo ý muốn của người sử dụng JWT. Tuy nhiên để tránh trùng lặp, khó nên được quy định ở trong IANA JSON Web Token Registry hoặc là 1 URI có chứa không gian tên không bị trùng lặp. Ví dụ:
"https://www.topdev.vn/jwt_claims/is_admin": true
Private: Phần thông tin thêm dùng để truyền qua giữa các client. Ví dụ
User thực hiện login bằng cách gửi id/password hay sử dụng các tài khoản mạng xã hội lên phía Authentication Server (Server xác thực)
Authentication Server tiếp nhận các dữ liệu mà User gửi lên để phục vụ cho việc xác thực người dùng. Trong trường hợp thành công, Authentication Server sẽ tạo một JWT và trả về cho người dùng thông qua response.
Người dùng nhận được JWT do Authentication Server vừa mới trả về làm “chìa khóa” để thực hiện các “lệnh” tiếp theo đối với Application Server.
Application Server trước khi thực hiện yêu cầu được gọi từ phía User, sẽ verify JWT gửi lên. Nếu OK, tiếp tục thực hiện yêu cầu được gọi.
Hệ thống Verify chuỗi JWT thế nào?
Câu hỏi đặt ra ở đây là hệ thống Verify JWT thế nào:
Chuỗi JWT có cấu trúc H.P.S được Client gửi lên. Server sẽ làm tương tự như sau
Set S1 = S
Set S2 = HMAC(SHA256(H.P) vỡi secret key của hệ thống) (Giả sử hệ thống sử dụng encryption algorithms SHA256)
So sánh S1 == S2 ?
Nếu S1 và S2 khớp nhau, tức là chữ ký hợp lệ, hệ thống mới tiếp decode payload và tục kiểm tra các data trong payload. Ví dụ trường exp (expiration date).
Khi nào sử dụng JWT?
Với JWT, bạn không cần phải giữ session data trên server để xác thực user. Luồng đi như sau:
Người dùng gọi authentication service để gửi username/password
Authentication service phản hồi cho người dùng mã JWT, cái này sẽ định nghĩa xem user là ai
Người dùng yêu cầu truy cập một dịch vụ được bảo mật bằng việc gửi token lên
Lớp bảo mật sẽ check chữ ký trên token và nếu đó là quyền truy cập hợp lệ thì được tiếp tục truy cập
Các sessions sẽ có thời hạn hết hạn và cần phải được xử lý kiểu xoá đi các session hết hạn này. JWT hoàn toàn có thể sở hữu chính expiry date của chính nó kèm với dữ liệu user. Cho nên khi tầng Security check authen của JWT, nó có thể check expiry time của token và đơn giản là từ chối truy cập.
Nếu không sử dụng session thì bạn mới có thể ứng dụng tạo một service thuần RESTful, bởi vì một service thuần RESTful được định nghĩa là phải stateless. Với dung lượng nhỏ, JWT có thể được gửi lên với mọi request cũng giống như session cookie. Nhưng ko giống với session cookie, nó ko cần phải trỏ đến bất kì dữ liệu nào được lưu trữ trên server, bản thân JWT đã có dữ liệu.
CÁCH VINFAST ĐẠT 1 TRIỆU CCU – HỆ THỐNG NHƯ THẾ NÀO LÀ ĐỦ MẠNH?
Một cú hích cho sản phẩm made-in-Vietnam từ tập đoàn VinGroup khi cho ra mắt 2 chiếc VinFast ra mắt tại Paris Motor Show thu hút hơn 8 triệu lượt đón xem trên toàn kênh của sự kiện livestream! Tuy nhiên bí quyết công nghệ đứng sau lượng băng thông “khủng” chiếm tới 1/10 băng thông toàn bộ mạng Internet Việt Nam tại thời điểm đó là gì?
Được “đặt hàng” trước nửa tháng từ ngày diễn ra Livestream thì công ty công nghệ VCCorp đã sử dụng công nghệ gì để đảm bảo lượng băng thông khủng từ 100 kênh báo chí lớn của Việt và gần 50 fanpage của các KOLs đặc biệt hơn khoảng cách địa lý ấn tượng từ Pháp
Và mục tiêu: đáp ứng tối thiểu 1 triệu CCU và mong muốn lên đến 4-5tr. Tại đây, băng thông là vấn đề lớn nhất, trong khả năng có thể huy động 1.4Tpbs (có thể 1 triệu -> 1.2 triệu users).
Sau “dấu mốc” lịch sử thì VCCorp đã có những phương án tối ưu như thế nào? Để đáp ứng các đòi hỏi về chất lượng và khó khăn về khoảng cách thì các chuyên gia chúng ta cần một hệ thống ra sao?
#VMD2019#VietnamMobileDay2019
Cập nhật nhiều hơn từ kinh nghiệm của các case study thực tế tại năm thứ 9!!!
NPM là gì? – NMP là viết tắt của Node package manager là một công cụ tạo và quản lý các thư viện lập trình Javascript cho Node.js. Trong cộng đồng Javascript, các lập trình viên chia sẻ hàng trăm nghìn các thư viện với các đoạn code đã thực hiện sẵn một chức năng nào đó. Nó giúp cho các dự án mới tránh phải viết lại các thành phần cơ bản, các thư viện lập trình hay thậm chí cả các framework.
Nếu trong project của bạn cần cài đặt cả chục scripts từ các thư viện khác nhau. Điều đó tương đương với việc bạn phải tải về source của chục thư viện, include chúng vào trong source của bạn. Một công việc tốn khá nhiều thời gian khủng khiếp.
Với npm , công việc sẽ đơn giản đi rất nhiều, chúng giúp bạn thực hiện việc quản lý đơn giản hơn rất nhiều. Các thư viện đều có sẵn trên npm, bạn chạy một dòng lệnh để tải về và dễ dàng include chúng hơn.
Mỗi đoạn code này có thể phụ thuộc vào rất nhiều các mã nguồn mở khác, thật may mắn khi các công cụ quản lý thư viện ra đời, nếu không sẽ mất rất nhiều công sức trong việc quản lý các thư viện này.
Cộng đồng sử dụng npm rất lớn, hàng nghìn các thư viện được phát hành, hỗ trợ Javascript ES6, React, Express, Grunt, Duo… Hiện nay cũng đã xuất hiện thêm Yarn một công cụ tương tự npm, được Facebook phát triển với nhiều tính năng vượt trội có khả năng sẽ thay thế npm.
Nếu như bạn từng code Php thì sẽ biết Composer là công cụ quản lý thư viện của nó, tương tự như NPM là công cụ quản lý thư viện Javascript.
npm có sẵn khi bạn tải NodeJS về. Để kiểm tra xem trên hệ thống của bạn đã được cài npm chưa chúng ta sử dụng lệnh npm -v, nếu một phiên bản hiện ra thì hệ thống của bạn đã được cài đặt npm.
Vì NPM là một phần mềm cài đặt trên máy tính của bạn nên bạn có thể sử dụng nó để cài đặt các thư viện Javascript từ trên Internet. Để cài đặt một thư viện nào đó, chỉ cần mở cửa sổ Terminal (hoặc CMD) và thực thi lệnh giống dưới đây:
npm install package-name
VD như mình thử tải Vuejs về sử dụng sẽ dùng lệnh:
npm install vue
Khi đó muốn sử dụng Vue.js chúng ta chỉ cần sử dụng lệnh require():
var Vue = require('vue');
Cài đặt global và cài đặt local
Có hai cách để cài đặt một gói bằng npm:
Local: sẽ tạo ra thư mục node_modules nếu chưa có trong project hoặc nếu có rồi nó sẽ lấy code của gói cần cài đặt đưa vào đây, tức chỉ hiện diện trong thư mục của project hiện tại. Khi cần sử dụng bạn có thể sử dụng lệnh require().
Global: sẽ lưu trữ code của gói trong các file hệ thống cố định trong máy, chỉ có thể dùng các package này thông qua các hàm CLI (Command Line Interface) ví dụ như gulp. Không thể dùng package thông qua require().
Mặc định thì các package khi cài đặt đều sẽ là cài trên project của bạn.
Trong thực tế, đôi khi có những gói thư viện bạn đã cài đặt nhưng sau đó bạn không sử dụng đến trong dự án, bạn có thể gỡ bỏ cài đặt một gói thông qua câu lệnh:
npm uninstall package_name
Các package thư viện đưa vào project của bạn có thể liên tục có update mới. Thực hiện npm update để thực hiện cập nhật tất cả các gói liên quan. Nếu bạn chỉ muốn cập nhật một gói cụ thể có thể sử dụng cú pháp:
npm update package_name
Các câu lệnh này có thể sử dụng flag -g để thực hiện cập nhật cho các gói được cài đặt global.
Kiểm tra các gói cài đặt
Để kiểm tra các gói đã được cài đặt thông qua npm sử dụng câu lệnh npm ls, nếu kiểm tra các cài đặt global thêm tham số -g
npm ls
npm ls -g
Package.json
Để quản lý các gói cài đặt cục bộ bằng npm thì cách tốt nhất là thông qua file package.json, chính là file nằm trong thư mục gốc của project. File JSON này chứa các nội dung:
Các gói thư viện lập trình mà project sử dụng.
Cho phép xác định phiên bản chính xác của các gói thư viện lập trình được sử dụng.
Các gói bạn xây dựng có thể chia sẻ dễ dàng với các lập trình viên khác trên toàn cầu thông qua npm.
Lệnh npm init –yes sẽ tạo ra file package.json mẫu.
Có một số các thuộc tính trong package.json, chúng ta cùng điểm qua:
name: tên gói thư viện
version: phiên bản gói
description: phần mô tả về gói thư viện
homepage: trang chủ của gói
author: tác giả
contributors: tên người đóng góp cho package
dependencies: danh sách các gói phụ thuộc, tự động được cài theo.
repository: loại repository và url của package, thông thường là git (Xem thêm Git là gì?)
main: index.js
keywords: các từ khóa
Ví dụ sử dụng file package.json, project sử dụng package random-keygen với phiên bản là 1.0.4 cho production và sử dụng gói develop-random-keygen trong quá trình develop là 1.0.2, file package.json sẽ như sau:
Nếu muốn thêm các entry vào thuộc tính dependencies khi cài đặt gói sử dụng thêm flag –save, còn với thuộc tính devDependencies thì sử dụng flag –save-dev.
Nói đến ứng dụng chat realtime, chắc ai cũng nghĩ ngay đến việc dùng thư viện hay service bên thứ 3 như websocket, Firebase RealTimeDatabase … phải không nào?
Mỗi công nghệ sẽ có ưu điểm, nhược điểm riêng, mà quan trọng nhất phải phù hợp với hệ thống hiện tại.
Vậy hãy cùng xem các kĩ sư Eureka tại sao chọn gRPC cho giải pháp của mình, và đã tối ưu nó như thế nào nhé.
Trước khi đi vào phần chính cùng tìm hiểu xem Eureka là công ty như thế nào đã nhé.
Eureka là công ty như thế nào
Công ty Eureka là công ty Nhật bản, được thành lập vào năm 2008, đến thời điểm hiện tại Eureka đã có 130 nhân viên.
Eureka đang vận hành 1 service về tình yêu và dịch vụ kết hôn lớn nhất Nhật Bản có tên là Pairs (Hay nói cách khác đây là 1 dịch vụ về hẹn hò thì đúng hơn).
Chức năng chính trong Pairs thì có rất nhiều nhưng mình chỉ điểm qua 1 số điểm chính thôi nhé:
Người dùng sẽ vào website đó để đăng kí tài khoản (có thể đăng kí thông qua Facebook). Sau đó sẽ chọn ảnh bạn gái mà mình yêu thích và like.
Nếu có cảm tình thì tiến hành nhắn tin hẹn hò.
Ban đầu Pairs sẽ cho mỗi tài khoản 1 số lượng point nhất định. Nếu dùng hết sẽ phải nạp thêm point.
Khi like hay nhắn tin thì bạn sẽ mất 1 phần point nào đó. Cứ 1 tin nhắn là 1 point chẳng hạn.
Điểm mà mình thích nhất ở Pairs đó là mặc dù mình đăng kí tài khoản thông qua Facebook. Nhưng Pairs sẽ luôn lựa chọn ảnh “bạn gái” mà không cùng Friend trên Facebook với mình (kể cả Friend của friend cũng không hiển thị ra luôn).
Vào đó hẹn hò lén lút mà gặp phải bạn thân của vợ thì … Mà thôi nói đến đây các bạn tự hiểu. =))
Vậy đến đây các bạn cũng hiểu đôi chút về Pairs của Eureka rồi phải không.
Tiếp theo chúng ta đi vào vấn đề chính nhé.
Vấn đề đang gặp phải
Như mình giới thiệu ở trên, Pairs có 1 chức năng gọi là “chat hẹn hò”. Thế nhưng, hiện tại chức năng này đang thực hiện theo hình thức polling (tức là cứ mấy giây sẽ request lên api server lấy dữ liệu 1 lần).
Chính vì điều đó mà tin nhắn được gửi đến đối phương sẽ bị delay mất khoảng mấy giây. (Tức là sau khi A gửi tin nhắn cho B thì sau khoảng mấy giây tin nhắn mới hiển thị trên màn hình của B).
Vì đây là app hẹn hò. Nếu tin nhắn mà bị delay nhiều như thế thì về UX không được thân thiện cho lắm. Nên Eureka quyết định cải thiện chức năng chat này.
Tại sao lại chọn gRPC?
Bài toán đã có, bước tiếp theo là tìm hướng giải quyết. Nói là tìm hướng giải quyết nhưng việc lựa chọn công nghê phù hợp quả thật là 1 vấn đề đau đầu.
Ngoài gRPC ra thì còn có 1 số công nghệ khác nữa có thể giải quyết được bài toán này. Nói không xa đó chính là WebSocket đã có từ rất lâu đời.
Hay 1 công nghệ mà message Facebook đang sử dụng đó là MQTT.
1 số dịch vụ bên thứ 3 cung cấp cũng đang rất nổi tiếng như AWS AppSync, Firebase RealTimeDatabase cũng chuyên cung cấp giải pháp gửi nhận real time.
Có rất nhiều thứ khác nữa, nhưng do mỗi thứ có ưu điểm nhược điểm riêng, cộng với việc công nghệ đó phải phù hợp với project hiện tại. Nên các kĩ sư Eureka quyết định chọn gRPC cho giải pháp lần này.
Dưới đây là 1 số lí do:
Ngôn ngữ chính của các kĩ sư Eureka là Golang. Mà gRPC thì cũng đang support Golang.
Trong 1 số ngôn ngữ mà Eureka đang sử dụng như go/java/swift thì gRPC có phương thức tự động sinh ra Document, Code dựa vào định nghĩa IDL.
Trong vấn đề giao tiếp dạng stream (là chức năng mới của HTTP/2) đều có sample hay interface khá đầy đủ. Nên không cần để ý đến tầng communication cũng được.
Pattern xung quanh interceptor cũng được trang bị rất đầy đủ nên việc implement cũng khá đơn giản.
Chỉ cần xem ví dụ hay code của phần grpc-middleware là thể sử dụng được ngay nên khá tiện.
Implement Two-way communication bằng gRPC
Trên proto, chỉ cần gắn stream vào trong request lẫn response là có thể sinh ra được interface dùng cho việc truyền thông Two-way ở phía client.
Vì cách thực thi nó sẽ khác nhau với từng ngôn ngữ, nên để hiểu rõ hơn các bạn có thể xem qua tutorial ở đây nhé: gRPC tutorial
Hướng cải thiện tốc độ
Cấu trúc hệ thống hiện tại đang như sau:
Cấu trúc sau khi đưa gRPC vào sẽ được thay đổi như sau:
Qua 2 cấu trúc bên trên, ta thấy sự khác nhau chủ yếu là ở phía receiver. Cụ thể như sau:
Vì đã thực hiện kết nối ngay từ đầu nên sẽ không mất cost kết nối HTTP nữa
Việc kết nối đến mysql để lấy message thì bây giờ không cần nữa.
Không tồn tại Polling.
Dựa vào cấu trúc như này sẽ thấy không còn sự delay của việc Polling nữa. Thay vào đó phía receiver có thể nhận được message ngay tức thì.
Cấu trúc toàn thể của hệ thống
Nhờ việc sử dụng RedisPubSub như là nơi giao tiếp giữa các server (mới và cũ) đã giúp cho người dùng có thể gửi và nhận message 1 cách tức thời.
Làm thế nào để release an toàn?
Chức năng chat có thể nói là 1 trong những chức năng chính của hệ thống Pairs, nên việc có bug xảy ra có thể gây ảnh hưởng vô cùng lớn.
Vì phạm vi ảnh hưởng vô cùng lớn nên khi có bất kì bug nào thì việc rollback, detect lỗi là điều vô cùng quan trọng.
Trước khi release thì test code là điều đương nhiên phải làm. Thế nhưng để co hẹp phạm vi ảnh hưởng, Eureka đã nghĩ đến việc sẽ release chức năng chat mới này trên thiết bị Android trước. Sau khi chạy ổn định sẽ release tiếp trên iOS.
Chính vì điều đó mà sơ đồ cấu trúc hệ thống ở bên trên mới có phần API cũ và API mới là như thế.
Cách quản lý proto
・Tách repository ra riêng
File proto sẽ không nằm trong repository của các platform (ios/android/serverside) mà sẽ nằm ra 1 repository riêng biệt. Và dùng git submodule để chèn nó vào trong các repository của platform.
・Cách generate document và code
1 trong số những điểm mạnh của gRPC là có thể generate document và code 1 cách tự động nhờ sử dụng protoc.
Hơn nữa chúng ta có thể dễ dàng viết command line Make để generate ra document và code như bên dưới:
Với gRPC đang gặp phải 1 vấn đề là rất khó khăn trong việc đo hiệu năng.
Thông thường, 1 request 1 response thì chỉ cần xem log nginx hay apache là có thể biết được request đó xử lý mất bao lâu, thời gian trung bình của latency là bao nhiêu.
Thế nhưng với dòng stream của gRPC thì lại khác, tương ứng với 1 request thì có bao nhiêu response, và khi nào sẽ trả về. Dữ liệu khi nào xảy ra, khi nào đến … đều không thể biết được.
Do đó nếu không cải thiện chỗ này thì khó có thể tính toán, đo đạc hiệu năng được.
Chính vì vậy, Eureka đã lưu 3 giá trị metrics ở bên dưới vào StackDriver & BigQuery và tiến hành đo đạc:
Thời gian (μs) lưu data đến database ở phía sender.
Thời gian (μs) broadcast message đến gRPC server.
Thời gian (μs) send message đến sender từ gRPC server.
Kết quả là tổng thời gian từ 1 -> 3 chỉ mất dưới 0.2s nên việc tối ưu tốc độ lần này có thể coi là thành công.
Ngoài ra nhờ có thể lấy được giá trị cụ thể này mà dễ dàng detect khi tổng thời gian vượt quá giá trị cho phép.
Sự hạn chế về mặt infrastructure, monitoring, AccessLog
Về phương diện implement code thì không gặp nhiều khó khăn, thế nhưng về phương diện vận hành, monitoring server thì đang gặp rất nhiều vấn đề. Cần phải mapping lại các error code, các metrics thì mới có thể đo đạc đươc. Cụ thể như sau:
Việc monitoring RateBase trên ELB (4xx, 5xx) thì bây giờ phải chuyển sang monitoring Rate của từng con gRPC server với mã error codes khác
Để đo đạc được latency trong giao tiếp stream thì cần phải lấy được giá trị về thời gian phát sinh dữ liệu (event), thời gian nhận dữ liệu, thời gian update dữ liệu.
Về Logging của Send với Receive trong Stream thì hiện tại chưa support, do đó cần phải viết lại Wrapper cho thằng ServerStream.
Phần giao tiếp với BackendTarget thì hiện tại AWS ALB chưa support HTTP2. TCPMode của AWS ELB cũng chưa support ALPN. Do đó hiện tại Eureka đang sử dụng NetworkLoadBalancer.
Kết luận
Mặc dù việc vận hành gRPC còn có chút try hard, nhưng với case tạo API mà sử dụng micro framework, hay với những dòng stream sử dụng HTTP/2 thì gRPC rất thích hợp và dễ dùng, dễ implement.
Nên nếu bạn nào đang có nhu cầu đưa gRPC vào hệ thống thì hi vọng bài viết này sẽ giúp các bạn 1 phần nào đó.
Nói chung Redux khá là phổ biến. Tuy nhiên, không phải tất cả chúng ta đều biết nó là gì và cách sử dụng nó ra sao. Trong bài này, chúng ta sẽ xem vài lý do tại sao nên sử dụng redux bằng cách phân tích những lợi ích mà nó mang lại và cách hoạt động của nó.
Redux là gì?
Redux là một predictable state management tool cho các ứng dụng Javascript. Nó giúp bạn viết các ứng dụng hoạt động một cách nhất quán, chạy trong các môi trường khác nhau (client, server, and native) và dễ dàng để test. Redux ra đời lấy cảm hứng từ tư tưởng của ngôn ngữ Elm và kiến trúc Flux của Facebook. Do vậy Redux thường dùng kết hợp với React.
Lý do ra đời Redux
Do yêu cầu cho các ứng dụng single-page sử dụng Javascript ngày càng trở lên phức tạp thì code của chúng ta phải quản lý nhiều state hơn.
State có thể bao gồm là data trả về từ phía Server và được cached lại hay như dữ liệu được tạo ra và thao tác ở phía client mà chưa được đẩy lên phía server. UI state cũng trở lên phức tạp vì chúng ta cần quản lý việc active Routes, selected tabs, spinners, điều khiển phân trang …vv.
Với Redux, state của ứng dụng được giữ trong một nơi gọi là store và mỗi componentđều có thể access bất kỳ state nào mà chúng muốn từ chúng store này.
Tại sao ta lại cần state management tool
Hầu hết các lib như React, Angular, etc được built theo một cách sao cho các components đến việc quản lý nội bộ các state của chúng mà không cần bất kỳ một thư viện or tool nào từ bên ngoài.
Nó sẽ hoạt động tốt với các ứng dụng có ít components nhưng khi ứng dụng trở lên lớn hơn thì việc quản lý states được chia sẻ qua các components sẽ biến thành các công việc lặt nhặt.
Trong một app nơi data được chia sẻ thông qua các components, rất dễ nhầm lẫn để chúng ta có thể thực sự biết nơi mà một state đang live. Một sự lý tưởng là data trong một component nên live trong chỉ một component. Vì vậy việc share data thông qua các components anh em sẽ trở nên khó khăn hơn.
Ví dụ, trong react để share data thông qua các components anh em, một state phải live trong component cha. Một method để update chính state này sẽ được cung cấp bởi chính component cha này và pass như props đến các components con.
Giờ chúng ta hãy tưởng tượng rằng nếu một state phải được chia sẻ giữa các component cách khá xa nhau trong một tree components và state này phải được passed từ một component đến một component khác cho đến khi nó đến được nơi mà nó được gọi.
Cơ bản là, state mà chúng ta đang nói đến phải được nhấc lên một component cha gần nhất và tiếp nữa cho đến khi nó đến được cái component tổ tiên chứa tất cả các components nó cần cái state này sau đó pass cái state này xuống @@. Điều này sẽ khiến state trở nên khó hơn trong việc maintain và less predictable.
Điều này khiến cho bộ phận quản lý state trong app trở lên bừa bộn cũng như app trở lên vô cùng phức tạp. Đó là lý do tại sao chúng ta cần một state management tool như Redux.
Hiểu cách Redux làm việc
Cái cách mà Redux hoạt động là khá đơn giản. Nó có 1 store lưu trữ toàn bộ state của app. Mỗi component có thể access trực tiếp đến state được lưu trữ thay vì phải send drop down props từ component này đến component khác.
Có 3 thành phần của Redux: Actions, Store, Reducers.
1. Actions
Actions đơn giản là các events. Chúng là cách mà chúng ta send data từ app đến Redux store. Những data này có thể là từ sự tương tác của user vs app, API calls hoặc cũng có thể là từ form submission.
Actions được gửi bằng cách sử dụng store.dispatch() method, chúng phải có một type property để biểu lộ loại action để thực hiện. Chúng cũng phải có một payload chứa thông tin. Actions được tạo thông qua một action creator. Ví dụ:
Reducers là các function nguyên thủy chúng lấy state hiện tại của app, thực hiện một action và trả về một state mới. Những states này được lưu như những objects và chúng định rõ cách state của một ứng dụng thay đổi trong việc phản hồi một action được gửi đến store.
Store lưu trạng thái ứng dụng và nó là duy nhất trong bất kỳ một ứng dụng Redux nào. Bạn có thể access các state được lưu, update state, và đăng ký or hủy đăng ký các listeners thông qua helper methods.
Tạo một store cho một login app:
const store = createStore(LoginComponent);
Các actions thực hiện trên một state luôn luôn trả về một state mới. Vì vậy, state này là đơn giản và dễ đoán.
Bây giờ, chúng ta đã biết hơn một chúng về Redux, hãy trở lại với ví dụ Login component và xem cách cách mà Redux có thể giúp chúng ta được gì.
Bạn có thể xem video Redux cơ bản của Giảng viên Nguyễn Đức Hoàng tại đây.
Tổng kết
Ở phạm vi bài này mình đã trình bày nguyên lý cơ bản và cách thức hoạt động của Redux là gì rồi. Để các bạn có thể nắm được cũng như hình dung nó sinh ra để làm việc gì, bài viết mới thể hiện được các tình huống đơn giản nhất thông qua ví dụ đơn giản.
Còn trong khi làm dự án thực tế công việc chủ yếu là tương tác với server (fetch data) và xử lý data sau đó, thì đó là về bất đồng bộ asynchronous và xử lý side-effect sau mỗi action được gọi.
Việc làm Reactjs giờ lương toàn nghìn đô không. Anh em vào tham khảo thêm.
LAMP là viết tắt của Linux, Apache, MySQL và PHP (cũng có thể là Python, Perl nhưng bài này chỉ nói về Php), mỗi trong số đó là các gói phần mềm riêng lẻ được kết hợp để tạo thành một giải pháp máy chủ web linh hoạt. Các thành phần này, được sắp xếp theo các lớp hỗ trợ lẫn nhau, tạo thành các stack phần mềm.
Stack của LAMP
Linux: là lớp đầu tiên trong stack. Hệ điều hành này là cơ sở nền tảng cho các lớp phần mềm khác.
Apache đóng vai trò một HTTP server dùng để xử lý các yêu cầu gửi tới máy chủ.
Mysql là cơ sở dữ liệu để lưu trữ mọi thông tin trên website.
PHP sau đó sẽ xử lý các nhiệm vụ cần thiết hoặc kết nối với CSDL MySQL để lấy thông tin cần thiết sau đó trả về cho Apache. Apache cuối cùng sẽ trả kết quả nhận được về cho máy khách đã gửi yêu cầu tới.
LEMP stack là gì?
Các thành phần cấu thành LEMP stack cũng gần tương tự với LAMP, chỉ khác là Apache sẽ được thay thế bởi Nginx. Nginx được đọc là “engine-x”, giải thích cho chữ E trong “LEPM”. Nginx có ưu điểm là cho phép xử lý tốc độ tải cao hơn đối với các HTTP request.
Hiện tại, Nginx đã đạt được thành tựu đáng kể khi nó bắt đầu được nhiều người sử dụng từ năm 2008 và hiện trở thành ứng dụng web server tiếng tăm thứ 2 sau Apache.
Kiến thức cơ bản
1. Phân quyền tệp và thư mục
Sử dụng máy chủ Linux việc phân quyền tệp và thư mục rất quan trọng. Ví dụ trong trường hợp người dùng upload files lên hệ thống mà bạn chưa phân quyền thư mục thì lúc này việc đọc và ghi file lên máy chủ sẽ xảy ra lỗi. Và máy chủ web sẽ trả về lỗi 500.
Phân quyền trong Linux có 3 quyền hạn cơ bản của một user/group nào đó trên một file/folder nào đó bao gồm:
– r (read) – quyền đọc file/folder. – w (write) – quyền ghi/sửa nội dung file/folder. – x (execute) – quyền thực thi (truy cập) thư mục. Đối với thư mục thì bạn cần phải có quyền execute thì mới dùng lệnh cd để truy cập vào được.
Tùy thuộc vào config hệ thống mà các file log sẽ nằm ở vị trí tương ứng. Ví dụ webite của bạn hiển thị một màn hình trắng tinh và không có bất cứ thông báo nào từ màn hình debug. Lúc này bạn cần xem log hệ thống xem sao nhé.
3. Cấu hình cơ sở dữ liệu (Database)
Để mở rộng hay backup một hệ thống cũng như để đảm bảo một cơ sở dữ liệu toàn vẹn, không bị mất mát trước những sự cố. Việc hiểu biết nơi, cách cấu hình cơ sở dữ liệu cũng khá quan trọng bạn có thể tìm hiểu thêm về cấu hình Mysql Replication.
4. Cài đặt package
Linux không cung cấp đầy đủ các package cho anh em developer, nó chỉ làm môi trường thôi, còn lại bạn cần package nào thì tải cái đó. Để tải package cần thiết ta có thể dùng lệnh apt hoặc là yum.
5. Chỉnh sửa file trực tiếp trên máy chủ
Nhiều lúc bạn sẽ gặp phải lỗi và phải hot fix trực tiếp trên server, hoặc config web server. Việc này đòi hỏi bạn phải biết cách sử dụng trình soạn thảo của Linux thông qua câu lệnh vi ít nhất bạn có thể mở file và chỉnh sửa file. Lúc này bạn sẽ cần một list các câu lệnh Linux thông dụng để làm việc cho tiện, search thêm Google mỗi khi cần dùng nhé.
Việc làm Php lương hơn nghìn đô cho anh em nào cần, anh em nào chưa đạt được thì ráng phấn đấu thêm.
Middleware là những đoạn mã trung gian nằm giữa các request và response. Nó nhận các request, thi hành các mệnh lệnh tương ứng trên request đó. Sau khi hoàn thành nó response (trả về) hoặc chuyển kết quả ủy thác cho một Middleware khác trong hàng đợi.
Ứng dụng Middleware là gì?
Hiện nay các Web Framework tân tiến đều sử dụng nó như là một phần của ứng dụng để kết nối các phần khác lại với nhau. Đối với các ứng dụng web, việc sử dụng Middleware một cách hiệu quả giúp chúng ta có thể tối giản được số lượng dòng code phải viết trong ứng dụng.
Một ví dụ phổ biến mà chúng ta thường phải dùng Middleware đó là các trang chỉ dành riêng cho admin và không cho phép người dùng bình thường có thể truy cập.
Với tư tưởng chung là cầu nối giữa tương tác của người dùng và hệ thống trong lập trình Web. Middleware sẽ đóng vai trò trung gian giữa request/response và các xử lý logic bên trong web server.
Do đó, Middleware trong các Framework cho ứng dụng Web (Laravel, Django, Rails, ExpressJS…), sẽ là các hàm được dùng để tiền xử lý, lọc các request trước khi đưa vào xử lý logic hoặc điều chỉnh các response trước khi gửi về cho người dùng.
Hiểu các khái niệm cơ bản của Laravel Middleware
Trong bài viết này, mình sẽ lấy ví dụ là dùng framework Laravel để hiểu khái niệm về middleware. Chúng ta sẽ xem xét cách tạo middleware tùy chỉnh trong một ứng dụng Laravel.
Sau khi tạo middleware tùy chỉnh của bạn, chúng ta sẽ khám phá các tùy chọn có sẵn để đăng ký nó với Laravel để nó có thể thực sự được gọi trong luồng xử lý yêu cầu.
Middleware trong Laravel là gì?
Middleware như là một cơ chế cho phép bạn tham gia vào luồng xử lý request của một ứng dụng Laravel. Trong một quá trình xử lý route điển hình của Laravel khi thực thi việc xử lý yêu cầu và middleware là một trong những class mà ứng dụng phải thông qua.
Vậy chính xác thì việc xử lý luồng yêu cầu Laravel là gì? Ví dụ: cần xác thực người dùng để quyết định xem họ có được phép truy cập đến route hiện tại hay không.
Yêu cầu đăng nhập
Chuyển hướng người dùng
Thay đổi/chuẩn hoá các tham số
Xử lý response được ứng dụng Laravel tạo ra
…
Thực tế, Laravel mặc định đã có sẵn một số middleware quan trọng. Việc xác thực người dùng cũng được chính middleware này thực thi.
Chúng ta sẽ tự tạo ra một middleware tùy biến trong phần này. Như đã nói ở trên, Laravel có sẵn các middleware quan trọng, tuy nhiên để đáp ứng thêm nhu cầu thì chúng ta cần phảo tạo thêm nhiều middleware khác. Nhưng chính xác thì middleware này sẽ làm gì?
Case study cụ thể nhất mà thực tiễn nhất là khi chúng ta truy cập trang web từ bất kỳ thiết bị di động nào, thì sẽ được chuyển hướng đến URL miền phụ tương ứng (vd: m.topdev.vn khi ta vào topdev.vn trên mobile) dành cho mobile với tất cả thông số chuỗi truy vấn còn nguyên vẹn. Tất nhiên bây giờ đã có responsive nhưng đôi khi một phiên bản mobile tinh gọn và tốc độ nhanh sẽ có những tác dụng hay ho khác
Trong middleware tùy chỉnh này, chúng ta sẽ kiểm tra user agent và user được chuyển hướng đến URL tương ứng trên di động nếu họ đang sử dụng thiết bị di động.
Chạy lệnh sau để tạo một template middleware MobileRedirect.
php artisan make:middleware MobileRedirect
Và bạn sẽ tạo ra một file app/Http/Middleware/MobileRedirect.php với code sau.
<?php
namespace App\Http\Middleware;
use Closure;
class MobileRedirect
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
return $next($request);
}
}
Việc triển khai của method handle dựa trên khung sườn của middleware, và logic chính của middleware mà bạn đang tìm cách triển khai nằm ở đây.
Có 2 loại middleware mà Laravel đang có — before middleware và after middleware.
Before middleware chạy trước khi yêu cầu thực sự được xử lý và phản hồi được tạo ra. Mặt khác, after middleware chạy sau khi yêu cầu được ứng dụng xử lý và phản hồi đã được xây dựng tại thời điểm này.
Trong trường hợp này, chúng ta cần chuyển hướng người dùng trước khi yêu cầu được xử lý và do đó nó sẽ được phát triển như một before middleware.
Tiếp tục chỉnh sửa file app/Http/Middleware/MobileRedirect.php với các nội dung sau.
<?php
namespace App\Http\Middleware;
use Closure;
class MobileRedirect
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
// check nếu request từ thiết bị di động
if ($request->mobile == "1") {
return redirect('mobile-site-url');
}
return $next($request);
}
}
Chúng ta sẽ kiểm tra sự tồn tại của tham số mobile và nếu có giá trị TRUE, người dùng sẽ được chuyển hướng đến URL trên thiết bị di động. Lúc này bạn cần sử dụng một thư viên phát hiện user agent để lấy thông tin user ở client.
Tiếp tục ta sẽ gọi $next($request) giúp yêu cầu được xử lý thêm. Điều quan trọng cần lưu ý trong trường hợp này là chúng ta đã thiết lập logic phát hiện thiết bị di động trước khi gọi $next($request), và nó trở thành before middleware.
Sau đó chúng ta tạo một after middleware để xử lý các yêu cầu trên.
<?php
namespace App\Http\Middleware;
use Closure;
class CustomMiddleWare
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
$response = $next($request);
/* Viết logic code ở đây nha */
return $response;
}
}
Lúc này, middleware tùy chỉnh của chúng ta gần như đã sẵn sàng để được test thử. Bạn cần phải đăng ký middleware của bạn trong Laravel. Ta mở file app/Http/Kernel.php
/**
* The application's global HTTP middleware stack.
*
* These middleware are run during every request to your application.
*
* @var array
*/
protected $middleware = [
\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
\Illuminate\Foundation\Http\Middleware\ValidatePostSize::class,
\App\Http\Middleware\TrimStrings::class,
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
];
Chúng tha thêm middleware tùy chỉnh của mình vào mảng trên sau:
Sau khi thêm vào, chúng ta thử truy cập vào bất kỳ route nào của Laravel bằng chuỗi truy vấn mobile=1 và xem kết quả, lúc này coi như chúng ta đã đăng ký thành công middleware do mình tạo. Đôi khi bạn chỉ muốn chạy middleware cho các route xác định hãy sử dụng $routeMiddleware.
Trong thời đại công nghệ ngày nay, việc quản lý và triển khai các ứng dụng phức tạp trên môi trường đám mây đã trở thành một thách thức lớn đối với các doanh nghiệp và nhà phát triển. Để đáp ứng nhu cầu này, nhiều công cụ và nền tảng đã ra đời, nhưng không gì nổi bật và phổ biến hơn Kubernetes. Được phát triển bởi Google và hiện nay là một dự án mã nguồn mở được cộng đồng quốc tế đón nhận rộng rãi, Kubernetes đã trở thành tiêu chuẩn vàng cho việc quản lý container. Vậy Kubernetes là gì? Nó hoạt động như thế nào để giúp các tổ chức đơn giản hóa việc quản lý hạ tầng ứng dụng? Hãy cùng chúng tôi khám phá trong bài viết này.
Kubernetes là gì?
Kubernetes (k8s) là một nền tảng mã nguồn mở tự động hoá việc quản lý, scaling và triển khai ứng dụng dưới dạng container hay còn gọi là Container orchestration engine. Nó loại bỏ rất nhiều các quy trình thủ công liên quan đến việc triển khai và mở rộng các containerized applications.
Gần đây, nhiều ứng dụng đã thực hiện container hoá bằng cách sử dụng docker và sử dụng nó như là môi trường production ngày càng tăng. Trên môi trường production, Vì việc cấu trúc hệ thống chạy bằng container chỉ sử dụng docker là rất khó khăn. Cho nên việc sử dụng một nền tảng Container orchestration engine như là k8s thì khá phổ biến hiện nay.
Kubernetes orchestration cho phép bạn xây dựng các dịch vụ ứng dụng mở rộng nhiều containers. Nó lên lịch các containers đó trên một cụm, mở rộng các containers và quản lý tình trạng của các containers theo thời gian.
Các ứng dụng production thực tế mở rộng nhiều containers. Các containers đó phải được triển khai trên nhiều server hosts. Kubernetes cung cấp khả năng phối hợp và quản lý cần thiết để triển khai các containers theo quy mô cho các workloads đó.
Kubernetes ban đầu được phát triển và thiết kế bởi các kỹ sư tại Google. Đây cũng là công nghệ đằng sau các dịch vụ đám mây của Google. Google đã và đang tạo ra hơn 2 tỷ container deployments mỗi tuần và tất cả đều được hỗ trợ bởi nền tảng nội bộ: Borg.
Nên sử dụng Kubernetes khi nào?
Các doanh nghiệp lớn, có nhu cầu thực sự phải scaling hệ thống nhanh chóng, và đã sử dụng container (Docker).
Các dự án cần chạy >= 5 container cùng loại cho 1 dịch vụ. (Ví dụ dùng >=5 máy cùng để chạy code website TopDev).
Các startup tân tiến, chịu đầu tư vào công nghệ để dễ dàng auto scale về sau.
Kubernetes giải quyết vấn đề gì?
Bằng việc sử dụng docker, trên 1 host bạn có thể tạo ra nhiều container. Tuy nhiên nếu bạn có ý định sử dụng trên môi trường production thì phải bắt buộc phải nghĩ đến những vấn đề dưới đây:
Việc quản lý hàng loạt docker host
Container Scheduling
Rolling update
Scaling/Auto Scaling
Monitor vòng đời và tình trạng sống chết của container.
Self-hearing trong trường hợp có lỗi xãy ra. (Có khả năng phát hiện và tự correct lỗi)
Service discovery
Load balancing
Quản lý data, work node, log
Infrastructure as Code
Sự liên kết và mở rộng với các hệ thống khác
Bằng việc sử dụng một Container orchestration engine như K8s có thể giải quyết được nhưng vấn đề trên đây. Trong trường hợp không sử dụng k8s, Thì sẽ phải cần thiết tạo ra cơ chế tự động hoá cho những cái kể trên, như thế thì cực kỳ tốn thời gian và không khả thi.
K8s quản lý thực thi các container sử dụng YAML để viết các Manifest.
Kubernetes là gì?
Sau khái niệm kubernetes là gì chúng ta hãy đến với chức năng của nó. Kubernetes quản lý các docker host và cấu trúc container cluster. Ngoài ra, khi thực thi các container trên K8s, bằng cách thực hiện replicas (tạo ra nhiều container giống nhau) làm cho hệ thống có sức chịu lỗi cao và tự động thực hiện load balancing. Thông qua cơ chế load balancing, chúng ta có thể tăng giảm số lượng container replica (auto scaling).
Khi thực hiện phân chia container vào các Node (docker host), dựa trên các loại docker host kiểu như “Disk SSD” hay “số lượng clock của CPU cao”… Hoặc dựa trên loại Workload kiểu như “Disk I/O quá nhiều”, “Băng thông đến một container chỉ định quá nhiều” … K8s sẽ ý thức được việc affinity hay anti-affinity và thực hiện Scheduling một cách hợp lý cho chúng ta.
Trong trường hợp không được chỉ định host cụ thể, K8s sẽ thực hiện scheduling tuỳ thuộc vào tình trạng CPU, memmory của docker host có trống hay không. Vì vậy, chúng ta không cần quan tâm đến việc quản lý bố trí container vào các docker host như thế nào.
Hơn nữa, trường hợp resource không đủ, thì việc auto scheduling của K8s cluster cũng sẽ được thực hiện tự động.
Được xây dựng theo quan điểm tính chịu lỗi cao, K8s thực hiện monitor các container theo tiêu chuẩn. Trong trường hợp bất ngờ nào đó, khi một container process bị dừng, K8s sẽ thực hiện Self-hearing bằng cách scheduling một container nữa.
Self-hearing là một khái niệm cự kỳ quan trọng trong k8s, nếu trường hợp có một node nào đó trong cluster xảy ra vấn đề ví dụ có thể là bị die, hay node đó được di chuyển đi. Cơ chế self-hearing sẽ tự động phục hồi mà không ảnh hưởng đến service.
Thêm nữa, ngoài việc monitor hệ thống, k8s còn có khả năng thiết lập health check bằng HTTP/TCP script.
Trường hợp sau khi auto scaling, phát sinh một vấn đề của endpoint đến container. Trong trường hợp sử dụng máy ảo, bằng việc setting load balancing endpoint sẽ được sử dụng như một VIP.
K8s cũng có một chức năng tương tự như vậy đó là Service. Service của k8s cung cấp chức năng load balancing cho hàng loạt các container được chỉ định. Việc tự động thêm, xoá container thời điểm scale là điều hiển nhiên, khi một container xảy ra sự cố thì tự động cách ly.
Khi thực hiện rolling update container thì việc đầu tiên k8s sẽ làm là cách ly container cho chúng ta, vì vậy k8s có thể đảm nhận việc quản lý các endpoint ở mức SLA cao.
Trong trường hợp cấu trúc một hệ thống sử dụng docker, nên phân tách nhỏ các chức năng trong kiến trúc Microservice.
Trong kiến trúc Microservice, để sử dụng các image container được tạo ra tương ứng với từng chức năng và deploy chúng thì chức năng Service discovery thực sự cần thiết.
K8s là một Platform nhưng có khả năng liên kết tốt với các hệ sinh thái bên ngoài, có nhiều middleware chạy trên các service của k8s, trong tương lai chắc chắn sẽ còn nhiều hơn nữa.
Ansible: Deploy container tới Kubernetes
Apache Ignite: Sử dụng Service Discovery của Kubernetes, tự động tạo và scaling k8s clkuster
Fluentd: gửi log của container trong Kubernetes
Jenkins: Deploy container đến Kubernetes
OpenStack：Cấu trúc k8s liên kết với Cloud
Prometheus: Monitor Kubernetes
Spark: Thực thi native job trên Kubernetes(thay thế cho YARN)
Spinnaker：Deploy container đến Kubernetes
Thêm nữa, K8s chuẩn bị một vài cơ thế để có thể mở rộng, thực thi chức năng độc lập, nó có thể sử dụng platform như là một framework. Bằng cách sử dụng khả năng mở rộng, chúng ta có thể thực hiện release một ReplicaSet mà k8s cung cấp.
Là server điều khiển các máy Worker chạy ứng dụng. Master node bao gồm 4 thành phần chính:
Kubernetes API Server: là thành phần giúp các thành phần khác liên lạc nói chuyện với nhau. Lập trình viên khi triển khai ứng dụng sẽ gọi API Kubernetes API Server này.
Scheduler: Thành phần này lập lịch triển khai cho các ứng dụng, ưng dụng được đặt vào Worker nào để chạy
Controler Manager: Thành phần đảm nhiệm phần quản lý các Worker, kiểm tra các Worker sống hay chết, đảm nhận việc nhân bản ứng dụng…
Etcd: Đây là cơ sở dữ liệu của Kubernetes, tất cả các thông tin của Kubernetes được lưu trữ cố định vào đây.
Worker node
Là server chạy ứng dụng trên đó. Bao gồm 3 thành phần chính:
Container runtime: Là thành phần giúp chạy các ứng dụng dưới dạng Container. Thông thường người ta sử dụng Docker.
Kubelet: đây là thành phần giao tiếp với Kubernetes API Server, và cũng quản lý các container
Kubernetes Service Proxy: Thành phần này đảm nhận việc phân tải giữa các ứng dụng
kubectl
Tool quản trị Kubernetes, được cài đặt trên các máy trạm, cho phép các lập trình viên đẩy các ứng dụng mô tả triển khai vào cụm Kubernetes, cũng như là cho phép các quản trị viên có thể quản trị được cụm Kubernetes.
Pod
Pod là khái niệm cơ bản và quan trọng nhất trên Kubernetes. Bản thân Pod có thể chứa 1 hoặc nhiều hơn 1 container. Pod chính là nơi ứng dụng được chạy trong đó. Pod là các tiến trình nằm trên các Worker Node. Bản thân Pod có tài nguyên riêng về file system, cpu, ram, volumes, địa chỉ network…
Image
Là phần mềm chạy ứng dụng đã được gói lại thành một chương trình để có thể chạy dưới dạng container. Các Pod sẽ sử dụng các Image để chạy.
Các Image này thông thường quản lý ở một nơi lưu trữ tập trung, ví dụ chúng ta có Docker Hub là nơi chứa Images của nhiều ứng dụng phổ biến như nginx, mysql, wordpress…
Deployment
Là cách thức để giúp triển khai, cập nhật, quản trị Pod.
Replicas Controller
Là thành phần quản trị bản sao của Pod, giúp nhân bản hoặc giảm số lượng Pod.
Service
Là phần mạng (network) của Kubernetes giúp cho các Pod gọi nhau ổn định hơn, hoặc để Load Balancing giữa nhiều bản sao của Pod, và có thể dùng để dẫn traffic từ người dùng vào ứng dụng (Pod), giúp người dùng có thể sử dụng được ứng dụng.
Label
Label ra đời để phân loại và quản lý Pod,. Ví dụ chúng ta có thể đánh nhãn các Pod chạy ở theo chức năng frontend, backend, chạy ở môi trường dev, qc, uat, production…
Thực hành Kubernetes
Phần thực hành sẽ giúp luyện tập với những khái niệm cơ bản ở phía trên của Kubernetes. Nội dùng phần này bao gồm việc cài đặt cụm Kubernetes gồm Master và Node thông qua Minikube.
Việc triển khai ứng dụng vào Kubernetes thông qua Deployment, sử dụng Service để giúp người dùng truy cập ứng dụng từ bên ngoài vào trong Kubernetes, và các thao tác quản trị như tăng giảm số bản sao của ứng dụng cũng như cập nhật phiên bản của ứng dụng.
Cài đặt Kubernetes bằng Minikube
Trong bài viết này, chúng tôi sử dụng chương trình Minikube, là chương trình thiết kế để giúp cho người mới tiếp cận được những khái niệm cơ bản nhất của Kubernetes. Minikube không được sử dụng cho môi trường chạy sản phẩm thật.
Ở trên đây là những khái niệm cơ bản nhất chúng tôi muốn đưa vào để giới thiệu cho bạn đọc. Kubernetes còn nhiều những khái niệm khác, dần dần chúng ta sẽ làm quen với các khái niệm này sau. Đây là link để các bạn follow cài đặt và chạy thử: https://kubernetes.io/docs/tutorials/hello-minikube/
Hiện nay các AWS, Azure hay Google Cloud cũng đang sử dụng rộng rãi Kubernetes vì tính ưu việt của nó, còn bạn đã thử chưa?
Setup và triển khai ứng dụng lên một hoặc nhiều server thực sự rất vất vả. Bạn phải cài đặt các công cụ và môi trường cần thiết cho ứng dụng, rồi đảm bảo ứng dụng chạy được. Chưa kể đến việc các môi trường trên nhiều server khác nhau thường không đồng nhất, dẫn đến nhiều rắc rối hơn. Docker là một công cụ mạnh mẽ ra đời giúp đơn giản hóa quá trình phát triển và triển khai phần mềm. Dưới đây là bài viết giới thiệu Docker là gì và các kiến thức cơ bản về Docker.
Docker là gì?
Docker là một nền tảng phần mềm giúp bạn building, deploying và running ứng dụng dễ dàng hơn bằng cách sử dụng các containers (trên nền tảng ảo hóa).
Ban đầu Docker được viết bằng Python, hiện tại đã chuyển sang Golang.
Docker đóng gói phần mềm thành các container tiêu chuẩn hóa, chứa đựng tất cả những thứ cần thiết để phần mềm hoạt động như thư viện, công cụ hệ thống, mã nguồn và thời gian chạy. Khi cần deploy app lên bất kỳ server nào, bạn chỉ cần run container của Docker thì app của bạn sẽ được khởi chạy ngay lập tức.
Khi sử dụng Docker, bạn có thể dễ dàng triển khai và mở rộng quy mô ứng dụng trong bất kỳ môi trường nào, đồng thời đảm bảo rằng mã nguồn của bạn sẽ luôn chạy được một cách ổn định.
Container là các gói phần mềm nhỏ gọn chứa tất cả các thành phần cần thiết của một ứng dụng như mã nguồn, thư viện, và các công cụ, giúp đảm bảo ứng dụng có thể chạy đồng nhất trên mọi môi trường.
Bằng cách đó, nhờ vào container, ứng dụng sẽ chạy trên mọi máy Linux khác bất kể mọi cài đặt tùy chỉnh mà máy có thể khác với máy được sử dụng để viết code.
Tại sao nên dùng Docker?
Theo một cách nào đó, Docker khá giống virtual machine. Nhưng tại sao Docker lại phát triển, phổ biến nhanh chóng? Đây là những nguyên nhân:
Tính dễ ứng dụng: Docker rất dễ cho mọi người sử dụng từ lập trình viên, sys admin… nó tận dụng lợi thế của container để build, test nhanh chóng. Có thể đóng gói ứng dụng trên laptop của họ và chạy trên public cloud, private cloud… Câu thần chú là “Build once, run anywhere”.
Tốc độ: Docker container rất nhẹ và nhanh, bạn có thể tạo và chạy docker container trong vài giây.
Môi trường chạy và khả năng mở rộng: Bạn có thể chia nhỏ những chức năng của ứng dụng thành các container riêng lẻ. Ví dụng Database chạy trên một container và Redis cache có thể chạy trên một container khác trong khi ứng dụng Node.js lại chạy trên một cái khác nữa. Với Docker, rất dễ để liên kết các container với nhau để tạo thành một ứng dụng, làm cho nó dễ dàng scale, update các thành phần độc lập với nhau.
Hiệu suất cao: Docker containers chia sẻ cùng một hệ điều hành kernel, giúp giảm thiểu tài nguyên hệ thống so với các máy ảo (VMs), dẫn đến hiệu suất cao hơn và chi phí thấp hơn.
Quản lý phụ thuộc dễ dàng: Docker giúp quản lý tất cả các phụ thuộc của ứng dụng trong một container, đảm bảo rằng không có sự mâu thuẫn phiên bản giữa các thư viện và công cụ.
Với xu hướng dịch chuyển sang microservices của các hệ thống lớn, Docker đang làm một thành phần cực kỳ quan trọng, làm cho nó trở thành một phần của nhiều công cụ DevOps. Hiện tại thế giới bắt đầu sử dụng thêm một công cụ quản lý container tiên tiến khác là Kubernetes (Đọc thêm bài Kubernetes là gì?)
Chọn bản cài đặt tương ứng với hệ điều hành của bạn và tiến hành cài đặt theo hướng dẫn đối với Linux còn Windows và MacOS thì bạn chỉ cần tải bản cài về và cài đặt như mọi application khác.
Xem video hướng dẫn cài đặt Docker:
Sau khi cài đặt xong để kiểm tra xem cài đặt thành công hay không?
Mở command line:
$ docker version$ docker info$ docker run hello-world
Các khái niệm liên quan
Docker là gì
Docker Engine : là thành phần chính của Docker, như một công cụ để đóng gói ứng dụng
Docker Hub : là một “github for docker images”. Trên DockerHub có hàng ngàn public images được tạo bởi cộng đồng cho phép bạn dễ dàng tìm thấy những image mà bạn cần. Và chỉ cần pull về và sử dụng với một số config mà bạn mong muốn.
Container: là một instance của một image. Bạn có thể create, start, stop, move or delete container dựa trên Docker API hoặc Docker CLI.
Docker Client: là một công cụ giúp người dùng giao tiếp với Docker host.
Docker Daemon: lắng nghe các yêu cầu từ Docker Client để quản lý các đối tượng như Container, Image, Network và Volumes thông qua REST API. Các Docker Daemon cũng giao tiếp với nhau để quản lý các Docker Service.
Dockerfile: là một tập tin bao gồm các chỉ dẫn để build một image .
Docker Volumes: là phần dữ liệu được tạo ra khi container được khởi tạo.
Docker Repository: là tập hợp các Docker Images cùng tên nhưng khác tags. VD: golang:1.11-alpine.
Docker Networking: cho phép kết nối các container lại với nhau. Kết nối này có thể trên 1 host hoặc nhiều host.
Docker Compose: là công cụ cho phép run app với nhiều Docker containers 1 cách dễ dàng hơn. Docker Compose cho phép bạn config các command trong file docker-compose.yml để sử dụng lại. Có sẵn khi cài Docker.
Docker Swarm: để phối hợp triển khai container.
Docker Services: là các containers trong production. 1 service chỉ run 1 image nhưng nó mã hoá cách thức để run image — sử dụng port nào, bao nhiêu bản sao container run để service có hiệu năng cần thiết và ngay lập tức.
Trên đây là những khái niệm cơ bản nhất về Docker. Ngoài ra còn nhiều khái niệm nữa như swarm, compose…
Có một vài khái niệm cần đào sâu hơn đó là Docker Images và Dockerfile
Docker Images
Docker image là một thành phần quan trọng trong hệ thống Docker, đóng vai trò như một mẫu chuẩn chứa tất cả các thành phần cần thiết để chạy ứng dụng. Cụ thể, một Docker image bao gồm mã nguồn, các thư viện, phụ thuộc và các cấu hình cần thiết cho ứng dụng. Nói cách khác, image là một tập hợp các file hệ thống và file thực thi được gói gọn lại để có thể chạy trong môi trường cô lập của Docker. Các đặc điểm chính của Docker Image:
Đọc Chỉ (Read-Only): Docker image là không thể thay đổi. Khi bạn khởi tạo một container từ một image, Docker sẽ tạo một lớp ghi đè (write layer) lên lớp image chỉ đọc đó.
Tầng (Layers): Một Docker image được xây dựng từ nhiều tầng khác nhau. Mỗi thay đổi trong Dockerfile (cấu hình cho image) tạo ra một tầng mới. Tầng này giúp tiết kiệm dung lượng và tối ưu hóa, bởi nếu nhiều container cùng sử dụng một image, các tầng giống nhau chỉ cần lưu trữ một lần.
Môi trường nhất quán: Docker image đảm bảo rằng ứng dụng sẽ chạy chính xác trong mọi môi trường, từ phát triển đến sản xuất, bởi tất cả phụ thuộc của ứng dụng đều được gói gọn trong image.
Một image sẽ được build dựa trên những chỉ dẫn của Dockerfile.
Dockerfile
Dockerfile là file config cho Docker để build ra image. Nó dùng một image cơ bản để xây dựng lớp image ban đầu. Một số image cơ bản: python, unbutu and alpine. Sau đó nếu có các lớp bổ sung thì nó được xếp chồng lên lớp cơ bản. Cuối cùng một lớp mỏng có thể được xếp chồng lên nhau trên các lớp khác trước đó.
Các config:
FROM — chỉ định image gốc: python, unbutu, alpine…
LABEL — cung cấp metadata cho image. Có thể sử dụng để add thông tin maintainer. Để xem các label của images, dùng lệnh docker inspect.
ENV — thiết lập một biến môi trường.
RUN — Có thể tạo một lệnh khi build image. Được sử dụng để cài đặt các package vào container.
COPY — Sao chép các file và thư mục vào container.
ADD — Sao chép các file và thư mục vào container.
CMD — Cung cấp một lệnh và đối số cho container thực thi. Các tham số có thể được ghi đè và chỉ có một CMD.
WORKDIR — Thiết lập thư mục đang làm việc cho các chỉ thị khác như: RUN, CMD, ENTRYPOINT, COPY, ADD,…
ARG — Định nghĩa giá trị biến được dùng trong lúc build image.
ENTRYPOINT — cung cấp lệnh và đối số cho một container thực thi.
EXPOSE — khai báo port lắng nghe của image.
VOLUME — tạo một điểm gắn thư mục để truy cập và lưu trữ data.
Tạo Demo
Tạo file Dockerfile
FROM golang:1.11 AS builderWORKDIR /go/src/docker-demo/COPY . .RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o docker-demo .FROM alpine:latestWORKDIR /root/COPY — from=builder /go/src/docker-demo .CMD [“./docker-demo”]
Kết quả in ra dòng chữ Learning Docker đã được code trong file main.go
Quy trình thực thi của một hệ thống sử dụng Docker
Như trong hình vẽ, một hệ thống Docker được thực thi với 3 bước chính :
Build -> Push -> Pull,Run
Build
Đầu tiên tạo một dockerfile, trong dockerfile này chính là code của chúng ta. Dockerfile này sẽ được Build tại một máy tính đã cài đặt Docker Engine. Sau khi build ta sẽ có được Container, trong Container này chứa ứng dụng kèm bộ thư viện của chúng ta.
Push
Sau khi có được Container, chúng ta thực hiện push Container này lên cloud và lưu tại đó.
Pull, Run
Nếu một máy tính khác muốn sử dụng Container chúng ta thì bắt buộc máy phải thực hiện việc Pull container này về máy, tất nhiên máy này cũng phải cài Docker Engine. Sau đó thực hiện Run Container này.
Khi xây dựng ứng dụng và cần scale một cách linh hoạt.
Khi bạn muốn không tốn khá nhiều thời gian để config máy local và server cùng một môi trường để chạy được ứng dụng. Bạn chỉ cần build 1 lần chạy ở nhiều nơi mà thôi.
Sản phẩm của công ty bạn cần một cách tiếp cận mới về xây dựng, đẩy lên server, thực thi ứng dụng một cách nhanh chóng dễ dàng.
Lần lượt hé lộ hàng trăm diễn giả mỗi năm, VMD2019 có gì đặc biệt với nhóm speaker về tech đầu tiên của chương trình? Cùng điểm qua 5 chuyên gia đứng sau những công nghệ đang dẫn đầu thị trường nhé:
Anh Vương Hoàng Kim | Head of Products – YOOSE
Topics: “How small mobile applications with the use of AI / Data projects can help big problems. A Vietnam Case Study”
Góc nhìn trực quan về công nghệ được chia sẻ bởi một chuyên gia kinh tế là việc mà anh Vương Hoàng Kim sẽ thực hiện tại VMD2019. Với kinh nghiệm trong các lĩnh vực Inventory Procurement, Scrum Product Owner, anh Kim sẽ chia sẻ những nội dung xoay quanh việc sử dụng mobile app và AI / Data projects để giải quyết các vấn đề công nghệ. Quả là một topic thú vị và mới lạ phải không các bạn?
Anh Đặng Ngọc Quảng | Tech Lead – Arrow Technologies & Technical Special tại GDG Hà Nội
Topic “Firebase and Android Architecture Components: fit like a glove”
Anh Đặng Ngọc Quảng – chuyên gia công nghệ đến từ Arrow Technologies và GDG sẽ đem đến VND2019 những nội dung hấp dẫn xoay quanh chủ đề đang được nhiều tín đồ công nghệ quan tâm nhất hiện nay: Làm sao kết hợp Firebase và Android Architecture Components một cách tối ưu nhất?
Mr. Kelvin Teo | Co-founder – Funding Societies | Modalku
“Future of Fintech & Mobile Payment: Disruptive Technologies and the Evolvement of the Banking Industry”
Tốt nghiệp Trường Kinh Doanh Harvard và Đại học Quốc Gia Singapore, anh Kelvin Teo thường được mời diễn thuyết tại các hội thảo lớn như ASEAN Capital Markets Conference, LendIt Shanghai, and Money2020 Singapore. Cùng chờ xem nội dung chia sẻ đến từ một trong Top 200 Fintech influencers của Châu Á có những gì thú vị các bạn nhé!!
Anh Nguyễn Quang Nhật | Android Team Lead – ALAX VN
Topics: Future of mobile technology
Với gần 10 năm kinh nghiệm trong lĩnh vực Native Mobile Development với cả 2 nền tảng iOS và Android cũng như thành thạo trong nhiều lĩnh vực khác nhau như full-stack technology, Software Architecture & Development Life, anh Nhật sẽ giúp các bạn đón đầu những xu thế về mobile technology đang làm mưa làm gió trên thế giới hiện nay qua những nội dung chuyên sâu cùng ví dụ thực tiễn.
Anh Bùi Xuân Yên | Lead Software Engineer and Head of Technology Research – Adbrix
Topics: What you have believed to be Analytics was merely a report : Introducing True Marketing Analytics
Góp mặt trong lĩnh vực marketing không thể thiếu chuyên gia Bùi Xuân Yên đến từ adbrix. Những số liệu cụ thể và chính xác sẽ được chia sẻ tại VMD2019 bởi chuyên gia hàng đầu trong lĩnh vực mạng cảm biến (sensor networks), giao thức Internet (Internet Protocols) và mạng di động (mobile networks). Nếu bạn là những nhà phân tích đang tìm kiếm sự đổi mới cho doanh nghiệp, bạn chắc chắn sẽ không muốn bỏ lỡ phần chia sẻ của anh Yên!!
5 chuyên gia trên đây đã đủ khiến bạn có hứng thú tham gia sự kiện vào tháng 6 sắp tới chưa? Nhanh tay đăng ký để giữ ngay cho mình 1 slot tham gia Vietnam Mobile Day cùng hơn 100 diễn giả “chất lừ” của chúng tôi nhé!
CODE giảm 30% vé tham dự cho độc giả: TOPDEVBLOG@VMD19
1 hệ thống cũng giống như thời tiết xấu vậy. Nó không thể đoán trước và cũng không thể tránh khỏi. Và điều quan trọng nhất đối với 1 software engineer là lập kế hoạch và giải quyết các vấn đề lỗi đó.
Trong bài viết này, mình sẽ giới thiệu cho các bạn 1 kĩ thuật có độ tin tưởng khá cao, hạn chế gây ra lỗi hệ thống mà các kĩ sư Grab đang dùng. Đó là kĩ thuật Circuit Breaker (Dịch sang tiếng việt nghĩa là bộ ngắt mạch, mình thì hay gọi nó là cái cầu giao).
Hiện tại, Grab đang sử dụng cơ chế Circuit Breaker trong toàn bộ hệ thống của họ. Để đảm bảo rằng khi có sự cố xảy ra đi chăng nữa thì service vẫn không bị chết, và vẫn tiếp tục phục vụ request của người dùng.
Đây có lẽ là điều mà nhiều engineer đang muốn biết phải không nào? Vậy hãy cùng đi xem cơ chế Circuit Breaker là gì? Và nó được áp dụng trong hệ thống của Grab như thế nào nhé.
Nguyên nhân gây ra lỗi hệ thống
Trước tiên chúng ta hãy thử xem xét đâu là nguyên nhân thường xuyên gây ra lỗi nhé.
Do service hay phải truyền thông với các tài nguyên bên ngoài, nên về cơ bản, thì lỗi có thể là do:
Vấn đề về mạng
Quá tải hệ thống
Cạn kiệt tài nguyên (ví dụ như out of memory …)
Cấu hình, deploy lỗi
Bad request (ví dụ như missing request data …)
Vậy khi có lỗi xảy ra, làm thế nào để tiếp tục xử lý được request thì chúng ta xem tiếp phần tiếp theo nhé.
Điện nhà bạn đã bao giờ tự nhiên đang dùng thì bị ngắt cầu giao chưa? Ví dụ như vừa bật nồi lẩu, vừa cắm nồi cơm, vừa bật máy giặt thì quá tải, cầu giao bị ngắt. Và cả nhà tối om như mực.
Thế nhưng điều đó ít nhiều vẫn còn an toàn hơn việc nhà không có cầu giao. Nếu không có cầu giao thì điều gì sẽ xảy ra?
Dùng quá tải, không có bộ phận ngắt điện kịp thời sẽ đẫn đến cháy nổ ở bộ phận nào đó trong nhà, gây chập điện… Khá là nguy hiểm.
Cơ chế Circuit Breaker mà Grab áp dụng trong hệ thống cũng hoạt động theo cách tương tự.
Circuit Breaker sẽ nằm giữa 2 đoạn code, và theo dõi luồng dữ liệu chảy qua nó. Tuy nhiên thay vì ngắt điện khi có sự cố, thì nó sẽ block request lại.
Để dễ hiểu hơn, các bạn có thể xem hình bên dưới:
Đầu tiên, “Main” (để dễ hiểu có thể coi nó như người dùng) sẽ call đến Circuit Breaker (cái này cũng nằm trong code của service). Sau đó từ Circuit Breaker sẽ gửi 1 request đến Upstream Service (Có thể hiểu nó như là 1 api server).
Khi đó Upstream Service sẽ xử lí request và trả về response đến Circuit Breaker. Nếu response đó không có lỗi gì thì sẽ được trả lại ngay “Main”.
Điều gì xảy ra nếu như Upstream Service bị lỗi?
Nếu có lỗi xảy ra phía Upstream Service thì nó sẽ trả về lỗi cho Circuit Breaker,và Circuit Breakersẽ trả lại lỗi cho Main.
Nhìn vào đây chắc hẳn các bạn cũng đang nghĩ: cho thằng Circuit Breaker vào giữa này chưa thấy có ưu điểm gì?
Vậy để mình giải thích nhé.
Giả sử như có 1000 request gửi đến Circuit Breaker và nó đang nhận được cả 1000 response lỗi từ Upstream Service.
Circuit Breaker sẽ ở giữa monitor những request đó và tracking xem có bao nhiêu request thành công và bao nhiêu request thất bại.
Nếu như số lượng request thất bại vượt qúa số lượng cho phép, khi đó nó sẽ phán đoán Upstream Service đang có vấn đề. Và nó sẽ ngắt mạch lại. Không cho request chảy sang bên Upstream Service nữa.
Ở trong trạng thái đó mà có gửi request sang đi chăng nữa thì response bạn nhận được cũng bị timeout hoặc lại càng làm cho Upstream Service “gánh tạ” nhiều hơn mà thôi.
Và flow bây giờ sẽ thành thế này:
Đến đây chắc các bạn cũng hình dung được phần nào ý nghĩa của thằng Circuit Breaker đúng không ạ?
Nhưng mà cũng có người đang thắc mắc, nếu cứ trả về lỗi như thế thì nó không có ý nghĩa gì cho người dùng lắm.
Ví dụ như mình muốn tìm kiếm xem từ điểm A đến điểm B sẽ đi mất bao lâu. Nhưng mà server của Grab lại toàn trả về lỗi. Khi đó bạn có suy nghĩ gì về trải nghiệm người dùng? Chắc chắn là không tốt rồi.
Chúng ta cùng đi xem tiếp xem Grab đã xử lý trường hợp này như thế nào nhé?
Fallback processing (xử lý dự phòng)
Để giải quyết bài toán này, Circuit Breaker đã định nghĩa ra 1 tính năng gọi là Fallback processing. Chúng ta cùng đi xem flow bên dưới xem nó hoạt động thế nào nhé.
Giả sử như các bạn đang xây dựng 1 chương trình tính khoảng cách giữa 2 điểm. Chúng ta gọi service đó là “distance calculator service”.
Nếu như service hoạt động bình thường, khi đó nó sẽ trả về cho chúng ta khoảng cách giữa 2 điểm.
Tuy nhiên, nếu “distance calculator service” đang quá tải, không thể xử lý thêm request.
Khi đó, Circuit Breakersẽ thực hiện fallback processing request của người dùng và thực hiện tính toán thay cho “distance calculator service” bằng việc sử dụng hàm lượng giác tính toán đơn giản.
Đương nhiên là tính toán khoảng cách sử dụng cách này sẽ không cho kết quả chính xác. Nhưng bằng cách này đã giúp Grab xử lý yêu cẩu của khách hàng tốt hơn rất nhiều so với việc không trả về kết quả gì.
Trong hình thức fallback processing, thì ví dụ mình đưa ra bên trên chỉ là 1 cách thôi. Ngoài ra còn 1 số cách khác nữa. Ví dụ như:
Retries request đến 1 con upstream service khác
Lưu request đó vào queue và sẽ xử lý lại vào thời gian khác.
Tuy nhiên, có 1 số trường hợp thì sử dụng fallback processing vẫn không hợp lý. Nhưng ít nhiều trong những hoàn cảnh như này, thì việc sử dụng 1 Circuit Breaker vẫn là có lợi.
Circuit Breaker có nên tracking mọi error?
Câu trả lời ngắn gọn là không.
Grab chỉ tracking những lỗi không phải do người dùng, mà do phía infrastructure hoặc network (Ví dụ với HTTP error code là 503 hoặc 500).
(Lỗi người dùng là lỗi thế nào? Chủ yếu là lỗi có HTTP error code là 400 hoặc 401.)
Lí do mà Grab không tracking lỗi do người dùng là do nếu như có phần tử hacker nào đó. Họ cố tình gửi thật nhiều request lỗi (ví dụ request thiếu parameter) đến Circuit Breaker. Khi đó Circuit Breakersẽ tự động ngắt mạch kết nối đến Upstream Service, và dẫn đến service bị down và không xử lý request của người khác được nữa.
Phục hồi Circuit Breaker như thế nào?
Sau khi Circuit Breakerđã ngắt mạch kết nối để không gửi request đến Upstream Service nữa. Vậy khi nào Circuit Breakersẽ thực hiện đóng mạch lại và tiếp tục gửi request đến Upstream Service?
Câu trả lời rất đơn giản. Nó sẽ đợi sau 1 thời gian nào đó (ví dụ như 1 phút), Grab gọi nó là Sleep Window.
Rồi sẽ test lại mạch bằng cách gửi 1 vài request nào đó đến Upstream Service. Nếu như nhận được response OK, khi đó nó sẽ tiến hành đóng mạch và cho hệ thống hoạt động như bình thường.
Nếu như vẫn bị lỗi, thì nó lại tiếp tục lặp lại quá trình trên cho đến khi ok thì thôi.
Bulwark (tường thành)
Grab đang sử dụng 1 thư viện có tên là Hystrix-Go để implement Circuit Breaker.Và trong thư viện này có bao gồm 1 chức năng khá quan trọng đó là Bulwark (bức tường thành).
Bulwark có nhiệm vụ sẽ monitor toàn bộ các request đến đồng thời được gửi đến Circuit Breaker và nó sẽ block nếu như số lượng request đồng thời vượt quá số lượng cho phép.
Hình thức này người ta hay gọi là rate-limiting.
Tại sao nó quan trọng? Như mình đã nói ở trên, 1 trong những lý do khiến service của bạn bị down đó là do nhận quá nhiều request cùng 1 lúc.
Chẳng hạn như service của bạn chỉ xử lý được 1000 request đồng thời. Nếu như có hacker nào đó thực hiện DDos service của bạn bằng cách gửi 1 triệu request cùng 1 lúc đến server của bạn. Mình khẳng định service của bạn sẽ bị down và ko thể làm việc tiếp được.
Đó là lí do tại sao mà Bulwark đã được tích hợp vào Hystrix-Go.
Implement Circuit Breaker
Hiện tại Grab đang sử dụng Hystrix-Go để implement thằng Circuit Breaker. Và thằng Hystrix-Go này có 1 vài setting chính mà mọi người nên để ý:
1. Timeout
Là khoảng thời gian tối đa thực hiện request.
2. Max Concurrent Requests (số request đồng thời lớn nhất)
Đây chính là phần Bulwark mà mình đã đề cập ở bên trên.
Giá trị mặc định của nó là 10. Nhưng chú ý là hằng số này không phải biểu thị “per second” đâu nhé. Vì có thể số request đồng thời nó gửi quá nhanh, chỉ tính bằng mili second chẳng hạn.
Nếu giá trị này quá lớn sẽ khiến service của bạn không đủ tài nguyên để xử lý.
3. Sleep Window
Đây là khoảng thời gian mà Circuit Breaker sẽ đợi trước khi nó gửi request đến Upstream Service để check xem đã hoạt động bình thường hay chưa.
Nếu cái này đặt quá thấp sẽ không có hiệu quả vì Circuit Breaker sẽ phải open/check thường xuyên. Còn nếu nó đặt quá cao thì sẽ hạn chế thời gian phục hồi.
4. Error Percent Threshold
Đây là giá trị biểu thị tỉ lệ phần trăm số request thất bại trước khi bị ngắt mạch.
Và còn rất nhiều các setting nữa, các bạn tự tìm hiểu ở trên trang chủ Hystricx-Go nhé.
Kết luận
Đến đây chắc các bạn cũng biết được cách xây dựng 1 Circuit Breaker là như nào, và nó có tác dụng gì cho hệ thống.
Xây dựng xong hệ thống là 1 chuyện, nhưng để hệ thống “không chết” là 1 chuyện hoàn toàn khác.
Hi vọng qua bài này sẽ cung cấp cho các bạn chút về kĩ thuật Circuit Breaker và solution trong việc thiết kế hệ thống có tính availability cao.
Design pattern là các giải pháp tổng thể đã được tối ưu hóa, được tái sử dụng cho các vấn đề phổ biến trong thiết kế phần mềm mà chúng ta thường gặp phải hàng ngày. Đây là tập các giải pháp đã được suy nghĩ, đã giải quyết trong tình huống cụ thể.
Design pattern có tác dụng gì?
Những lập trình viên có thể áp dụng giải pháp này để giải quyết các vấn đề tương tự. Các vấn đề mà bạn gặp phải có thể bạn sẽ tự nghĩ ra cách giải quyết nhưng có thể nó chưa phải là tối ưu.
Bạn cần phải hiểu rõ nó không phải là ngôn ngữ cụ thể nào cả. Design patterns có thể thực hiện được ở phần lớn các ngôn ngữ lập trình. Nó giúp bạn giải quyết vấn đề một cách tối ưu nhất, cung cấp cho bạn các giải pháp trong lập trình hướng đối tượng (OOP).
Giúp sản phẩm của chúng ta linh hoạt, dễ dàng thay đổi và bảo trì hơn.
Có một điều luôn xảy ra trong phát triển phần mềm, đó là sự thay đổi về yêu cầu. Lúc này hệ thống phình to, các tính năng mới được thêm vào trong khi performance cần được tối ưu hơn.
Design pattern cung cấp những giải pháp đã được tối ưu hóa, đã được kiểm chứng để giải quyết các vấn đề trong software engineering. Các giải pháp ở dạng tổng quát, giúp tăng tốc độ phát triển phần mềm bằng cách đưa ra các mô hình test, mô hình phát triển đã qua kiểm nghiệm.
Những lúc khi bạn gặp bất kỳ khó khăn đối với những vấn đề đã được giải quyết rồi, design patterns là hướng đi giúp bạn giải quyết vấn đề thay vì tự tìm kiếm giải pháp tốn kém thời gian.
Giúp cho các lập trình viên có thể hiểu code của người khác một cách nhanh chóng (có thể hiểu là các mối quan hệ giữa các module chẳng hạn). Mọi thành viên trong team có thể dễ dàng trao đổi với nhau để cùng xây dựng dự án mà không tốn nhiều thời gian.
Khi nào nên sử dụng Design pattern?
Việc sử dụng các design pattern sẽ giúp chúng ta giảm được thời gian và công sức suy nghĩ ra các cách giải quyết cho những vấn đề đã có lời giải. Lợi ích của việc sử dụng các mô hình Design Pattern vào phần mềm đó chính là giúp chương trình chạy uyển chuyển hơn, dễ dàng quản lý tiến trình hoạt động, dễ nâng cấp bảo trì, …
Tuy nhiên điểm bất cập của design pattern là nó luôn là một lĩnh vực khá khó nhằn và hơi trừu tượng. Khi bạn viết code mới từ đầu, khá dễ dàng để nhận ra sự cần thiết phải có mẫu thiết kế. Tuy nhiên, việc áp dụng mẫu thiết kế cho code cũ thì khó khăn hơn.
Khi sử dụng những mẫu design pattern có sẵn thì chúng ta sẽ đối mặt với một vấn đề nữa là perfomance của product (code sẽ chạy chậm chẳng hạn). Cần phải chắc chắn là bạn đã hiểu toàn bộ mã nguồn làm việc như thế nào trước khi đụng vào nó. Việc này có thể là dễ dàng hoặc là đau thương, phụ thuộc vào độ phức tạp của code.
Hiện nay chúng ta đang áp dụng rất nhiều design pattern vào công việc lập trình của mình. Nếu bạn thường tải và cài đặt các thư viện, packages hoặc module nào đó thì đó là lúc bạn thực thi một design pattern vào hệ thống.
Tất cả các framework cho ứng dụng web như Laravel, Codeigniter… đều có sử dụng những kiến trúc design pattern có sẵn và mỗi framework sẽ có những kiểu design pattern riêng.
Web server là máy chủ cài đặt các chương trình phục vụ các ứng dụng web. Webserver có khả năng tiếp nhận request từ các trình duyệt web và gửi phản hồi đến client thông qua giao thức HTTP hoặc các giao thức khác. Có nhiều web server khác nhau như: Apache, Nginx, IIS, … Web server thông dụng nhất hiện nay:
Web server hoạt động như thế nào?
Mô hình hoạt động cơ bản của 1 web server
Bất cứ khi nào bạn xem một trang web trên internet, có nghĩa là bạn đang yêu cầu trang đó từ một web server. Khi bạn nhập URL trên trình duyệt của mình (ví dụ: https://topdev.vn) nó sẽ tiến hành các bước sau để gửi lại phản hồi cho bạn.
1. Trình duyệt phân giải tên miền thành địa chỉ IP
Trình duyệt web của bạn trước tiên cần phải xác định địa chỉ IP nào mà tên miền topdev.vn trỏ về. Trình duyệt sẽ yêu cầu thông tin từ một hoặc nhiều máy chủ DNS (thông qua internet). Máy chủ DNS sẽ cho trình duyệt biết địa chỉ IP nào tên miền sẽ trỏ đến cũng là nơi đặt trang web.
Lúc này trình duyệt web đã biết địa chỉ IP của trang web, nó có thể yêu cầu URL đầy đủ từ webserver.
2. Webserver gửi lại client Trang được yêu cầu
Web server phản hồi bằng cách gửi lại những thông tin client yêu cầu… Nếu trang không tồn tại hoặc có lỗi khác xảy ra, nó sẽ gửi lại thông báo lỗi thích hợp.
3. Trình duyệt hiển thị trang web
Trình duyệt web của bạn nhận lại được các tập tin html css (nhiều file khác)… và render hiển thị trang theo yêu cầu.
Giới thiệu một số Web Server phổ biến
Apache HTTP server
Apache là web server được sử dụng rộng rãi nhất thế giới. Apache được phát triển và duy trì bởi một cộng đồng mã nguồn mở dưới sự bảo trợ của Apache Software Foundation. Apache được phát hành với giấy phép Apache License là được sử dụng tự do, miễn phí.
Tính đến tháng 8 năm 2018, apache ước tính phục vụ cho 54.2% các trang web đang hoạt động và 53.3% số máy chủ hàng đầu. Apache chạy trên các hệ điều hành như windows, linux, unix, MacOS ….
Nginx
Nginx là một web server nhẹ (Đọc thêm Nginx là gì), không chiếm nhiều tài nguyên của hệ thống. Nginx còn là một reserse proxy mã nguồn mở. Nginx khá là ổn định, cấu hình đơn giản và hiệu suất cao.
Nginx được phát triển bởi Igor Sesoev vào năm 2002 chủ yếu là để phục vụ cho website rambler.ru (trang web được truy cập nhiều thứ hai của nước Nga). Theo thống kê của Netcaft, trong một triệu website lớn nhất thế giới có 6.52% sử dụng Nginx.
Nginx là phần mềm mã nguồn mở và miễn phí, được phát hành rộng rãi theo giấy phép BSD. Nginx được phát triển bằng ngôn ngữ và chạy được trên các hệ điều hành như Linux, FreeBSD, Windows, MacOS…
Nginx có các tính năng như chứng thực người dùng, virtual hosting, hỗ trợ CGI, FCGI, SCGI, WCGI, SSI, ISAPI, HTTPS, Ipv6, …
Internet Information Services (IIS)
IIS do Microsoft phát triển, sản phẩm này được tích hợp cùng với hệ điều hành Windows Server. Trong IIS bao gồm nhiều dịch vụ như: dịch vụ Web Server, dịch vụ FTP Server. Tính đến thời điểm tháng 5 năm 2015 thì thì số lượng trang Web sử dụng máy chủ IIS gần 248 triệu trang web.
Tất cả các tính năng của web server được quản lí độc lập do đó chúng ta có thể dễ dàng thêm, loại bỏ hoặc thay thế các tính năng của web server.
Nhờ được tích hợp ASP.NET IIS có thể sử dụng toàn bộ sức mạnh của ASP.NET. Module ASP.NET làm cho máy chủ phát triển nhanh chóng nhờ vào giao diện quen thuộc và các dịch vụ ứng dụng của ASP.NET.
Apache Tomcat
Apache Tomcat là một Java Servlet được phát triển bởi Apache Software Foundation. Tomcat thực thi các ứng dụng Java Servlet và JavaServer Pages (JSP). Tomcat cung cấp một máy chủ HTTP cho ngôn ngữ Java thuần túy.
Apache Tomcat rất ổn định và có tất cả các tính năng của một ứng dụng web thương mại nhưng đi kèm theo giấy phép mã nguồn mở của Apache. Tomcat cũng cung cấp một số chức năng bổ sung như tomcat manager application, speciallized realm imlementation và tomcat valves.
Các phiên bản của apache tomcat trùng với phiên bản và đặc điểm kỹ thuật của servlet java hoặc java servlet API. Tomcat 5.5X hỗ trợ Servlet API 2.3, tomcat 6.0X hỗ trợ servlet API 2.4 và tomcat 7.0 hỗ trợ servlet API 3.0. Ngoài Servlet versions API, phiên bản tomcat hỗ trợ phiên bản JSP API tương ứng.
Apache Tomcat hỗ trợ các hệ điều hành như windows, linux, MacOS, BSD,…
Lighttpd
Lighttpd là một phần mềm mã nguồn mở, an toàn và linh hoạt, đặc biệt miễn phí và được phân phối theo giấy phép BSD. Lighttpd được viết bởi Jan Kneschke. Lighttpd chiếm ít tài nguyên, memory thấp, CPU nhỏ. Lighttpd được phát triển bằng ngôn ngữ C. chạy trên hệ điều hành Linux, Windows, Mac OS,…
SQL Injection là một kỹ thuật lợi dụng những lỗ hổng về câu truy vấn của các ứng dụng. Được thực hiện bằng cách chèn thêm một đoạn SQL để làm sai lệnh đi câu truy vấn ban đầu, từ đó có thể khai thác dữ liệu từ database. SQL injection có thể cho phép những kẻ tấn công thực hiện các thao tác như một người quản trị web, trên cơ sở dữ liệu của ứng dụng.
Ví dụ thực tiễn SQL Injection
Ví dụ, trong form đăng nhập, người dùng nhập dữ liệu, trong trường tìm kiếm người dùng nhập văn bản tìm kiếm, trong biểu mẫu lưu dữ liệu, người dùng nhập dữ liệu cần lưu. Tất cả các dữ liệu được chỉ định này đều đi vào cơ sở dữ liệu.
Thay vì nhập dữ liệu đúng, kẻ tấn công lợi dụng lỗ hổng để insert và thực thi các câu lệnh SQL bất hợp pháp để lấy dữ liệu của người dùng… SQL Injection được thực hiện với ngôn ngữ lập trình SQL. SQL (Structured Query Language) được sử dụng để quản lý dữ liệu được lưu trữ trong toàn bộ cơ sở dữ liệu.
Tuy nhiên ngày nay chứng ta thường làm việc trên những framework hiện đại. Các framework đều đã được test cẩn thận để phòng tránh các lỗi, trong đó có SQL Injection.
Sự nguy hiểm của SQL Injection
Hack tài khoản cá nhân.
Ăn cắp hoặc sao chép dữ liệu của trang web hoặc hệ thống.
Thay đổi dữ liệu nhạy cảm của hệ thống.
Xóa dữ liệu nhạy cảm và quan trọng của hệ thống.
Người dùng có thể đăng nhập vào ứng dụng với tư cách người dùng khác, ngay cả với tư cách quản trị viên.
Người dùng có thể xem thông tin cá nhân thuộc về những người dùng khác, ví dụ chi tiết hồ sơ của người dùng khác, chi tiết giao dịch của họ,…
Người dùng có thể sửa đổi cấu trúc của cơ sở dữ liệu, thậm chí xóa các bảng trong cơ sở dữ liệu ứng dụng.
Người dùng có thể kiểm soát máy chủ cơ sở dữ liệu và thực thi lệnh theo ý muốn.
Việc kiểm tra lỗ hổng này có thể được thực hiện rất dễ dàng. Đôi khi ta chỉ cần nhập ký hiệu ' hoặc " vào các trường được kiểm tra. Nếu nó trả về bất kỳ thông báo bất ngờ hoặc bất thường, thì ta có thể chắc chắn rằng SQL Injection khả thi cho trường đó.
Ví dụ: một Form đăng nhập như sau
Và đoạn code server xử lý của bạn:
if(isset($_POST['username']) && isset($_POST['password'])){
$sql = "SELECT * FROM tbl_user WHERE username='". $_POST['username'] . "' AND password = '" .$_POST['password'] ."'";
}
Nếu như người dùng không nhập bình thường nữa mà chẳng hạn như họ có thêm một dấu nháy ' hoặc " vào thì dòng code của bạn sẽ bị lỗi ngay. Hoặc họ có thể sửa thành một câu truy vấn luôn luôn đúng như sau.
SELECT * FROM tbl_user WHERE username = '' OR '1' = '1' and password = '' OR '1' = '1'
Hoặc chèn thêm một câu lệnh truy vấn phía sau:
VD:
SELECT * FROM tbl_user WHERE username = 'admin' and password = 'admin'; Drop table users;
Các phần dễ bị tấn công
Các phần dễ bị tấn công bao gồm:
Form đăng nhập
Form tìm kiếm
Form nhận xét
Bất kì trường lưu hoặc trường đầu vào của dữ liệu
Liên kết của website
Cần lưu ý là trong khi thử nghiệm chống lại tấn công này là không thể chỉ kiểm tra một hoặc một vài trường bởi vì một trường có thể được bảo vệ chống lại SQL Injection, nhưng một trường khác thì không. Do đó, điều quan trọng là đừng quên kiểm tra tất cả các trường của trang web.
Cách giảm thiểu và phòng ngừa SQL Injection
Luôn kiểm tra kỹ các trường nhập dữ liệu và các bạn cần ràng buộc thật kỹ dữ liệu người dùng nhập vào.
Ví dụ:
//Thông thường
$id = $_GET['id'];
//Ràng buộc
$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;
Dùng Regular Expression để loại bỏ đi các ký tự lạ hoặc các ký tự không phải là số.
Hoặc dùng các hàm có sẵn để giảm thiểu lỗi. Mỗi khi truy vấn thì mọi người nên sử dụng thêm hàm mysqli_real_escape_string để chuyển đổi một chuỗi thành một query an toàn.
$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;
$sql= 'SELECT * FROM tbl_user WHERE id= ' . mysqli_real_escape_string($id);
Và lời khuyên cuối cùng là chúng ta nên dùng các Framework và hạn chế dùng code thuần tối đa nếu có thể. Framework luôn có cộng đồng hoặc các chuyên gia bảo mật giúp tìm lỗi và update liên tục, từ đó chúng ta có thể giảm bớt thời gian xử lý lỗi để tăng thời gian làm sản phẩm cũng là một điều hay.
Các nhà marketer luôn thu thập và tìm kiếm dữ liệu hàng thập kỷ. Thế nhưng một vấn đề khác bên lề xuất hiện: khối lượng và sự đa dạng của dữ liệu nở rộ. Giờ đây dữ liệu không còn quá hiếm hay quá khó khăn để tìm kiếm. Dữ liệu xuất hiện ở bất kỳ đâu, thậm chí nhiều doanh nghiệp còn không thể theo kịp.
Cùng lúc đó, sự mong đợi của khách hàng lại càng tăng cao. Người tiêu dùng mong chờ sự liên quan mật thiết và các trải nghiệm hữu ích từ các nhãn hàng ở từng thời điểm nhỏ nhặt nhất trong quá trình mua hàng của mình.
Điều này thúc đẩy sự đổi mới trong chiến lược từ các doanh nghiệp. Giờ đây các nhãn hàng không thể ngồi im với hàng tá dữ liệu nữa, nếu không muốn đánh mất những vị khách thiếu kiên nhẫn (Theo khảo sát số người có trải nghiệm thương hiệu không tích cực sẽ giảm 62% khả năng mua hàng trong tương lai.) Hoặc tệ hơn, họ sẽ đuối sức trên trận chiến sinh tồn trong một thị trường luôn thay đổi.
Để sử dụng dữ liệu hiệu quả, bạn đã làm chủ được dữ liệu của mình chưa? Dữ liệu chính là nguồn tài nguyên mới. Nếu sở hữu hàng trăm triệu terabyte dữ liệu không được khai thác thì cũng không có công dụng gì.
Lúc này mới thấy được tầm quan trọng của việc xây dựng chiến lược dữ liệu. các nhà lãnh đạo phải áp dụng một bản kế hoạch mới để thu thập và quản lý dữ liệu cho phù hợp, từ đó bất kỳ ai cũng có thể truy cập và phân tích thông tin, tích hợp các các công nghệ để thực hiện các mong đợi của khán giả .
Tôn trọng dữ liệu
Đây là yêu cầu hàng đầu của một nhà marketer thực thụ. 56% các leader đạt mục tiêu trong năm ngoái sẽ đồng ý mạnh mẽ rằng các quyết định dựa trên data sẽ vượt trội hơn so với dựa trên bản năng hay kinh nghiệm.
Đối với các marketer đang “chiến đấu” với các thử thách mà dữ liệu mang lại, như thiếu sự tích hợp, trích xuất data từ kho thông tin khổng lồ, sẽ có những khó khăn và sai lầm trên hành trình này, nhưng từ đây sẽ xuất hiện những kinh nghiệm quý giá.
“Bạn không thể ngã dọc đường nếu sức đẩy không đủ mạnh”
Xây dựng chiến lược của riêng mình và chuẩn bị trước những trở ngại
Câu hỏi được đặt ra là làm thế nào để doanh nghiệp có thể phát triển chiến lược dữ liệu của riêng mình? Đây là cả một quá trình chứ không phải là cuộc chạy đua nước rút, một cuộc đua trải dài những rào cản về kỹ thuật và cả con người. song các doanh nghiệp cần có sự đầu tư về chiến lược mạnh mẽ và cơ sở độc quyền để có thể thấy được lợi ích về lâu dài.
Có “Ba cái thiếu” không nên bỏ qua.
Thiếu tự tin: câu chuyện về data rất khó kể và thực hiện, nhưng với sự trợ giúp của công nghệ, bạn đã thành công một nửa chặng đường.
Thiếu niềm tin. “Tại sao phải thử?” là câu hỏi muôn thuở. Thành công hay thất bại đề là bước đệm cho những vòng tiếp theo.
Thiếu thời gian: sử dụng data ngốn hết thời gian và công sức, và thời gian là vấn đề chung trong kinh doanh. Song những người không có thời gian thường bỏ lỡ những dữ liệu có giá trị nhất.
Lập kế hoạch hành động
Không chỉ riêng các leader mới có chiến lược phân tích dữ liệu, mà 33% các nhà marketer hàng đầu nhận định các chiến lược giúp xác định cách tích hợp dữ liệu và công nghệ liên quan.
Với nền tảng công nghệ cho phép nhìn thấy sự tham gia của người tiêu dùng từ đầu đến cuối, hiệu suất truyền thông có thể được đánh giá tốt hơn vì có thể truyền tải thông điệp phù hợp với người tiêu dùng dựa trên hành vi của họ. Khi các dữ liệu được sắp xếp logic, mong muốn thầm kín của người tiêu dùng có thể được khai thác từ đó điều chỉnh các kế hoạch để đáp ứng với nhu cầu của người tiêu dùng.
***
Tại nơi mà hành vi người tiêu dùng thay đổi xoành xoạch, cần những chiến lược dữ liệu tích hợp để tạo nên nền tảng vững chắc vượt qua những cuộc thay đổi địa chấn. IGAWorks, thành lập năm 2006, là công ty công nghệ – quảng cáo tích hợp (full stack ad-tech company) và nhóm các dịch vụ toàn cầu đi đầu trong các lĩnh vực digital marketing và mobile business. IGAWorks cung cấp các giải pháp bao gồm nền tảng marketing trên truyền thông toàn cầu dựa trên AI, dự đoán ROI cho các bước mobile marketing của khách hàng.
Là một phần của IGAWorks, adbrix là nền tảng dữ liệu di động thế hệ tiếp theo. Được đưa vào hoạt động từ 2014, adbrix là nền tảng marketing và đối tượng dữ liệu cho các marketing tăng trưởng của di động với 27.000 ứng dụng và hơn 1000 đối tác truyền thông toàn cầu. Là công cụ thân thiện với marketer, adbrix cung cấp phân tích dữ liệu người dùng thô không giới hạn và phân tích chúng. Thu thập và phân tích dữ liệu hiệu suất quảng cáo cùng với dữ liệu đối tượng để phân đoạn mức dữ liệu sâu hơn của riêng người dùng, từ đó có thể sử dụng ngay cho các kế hoạch marketing.
adbrix được sử dụng rộng rãi trên toàn cầu, hơn 50 tỷ lượt nhấp quảng cáo hàng tháng, 800 triệu thiết bị và doanh thu 8,2 tỷ đô la trong ứng dụng năm 2019. Cùng với giải pháp nhắm gửi tin nhắn đẩy đầu tiên trên thế giới – Growth Action sẽ cho phép các marketer:
Đo đường hiệu suất chiến dịch quảng cáo trên thiết bị theo các kênh truyền thông
Phân tích hành vi người dùng theo từng số liệu
Tối ưu hoá thực hiện ngân sách marketing bằng cách phân bố lại các phương tiện & nhắm mục tiêu người dùng trong bảng tuỳ chỉnh dashboard
Xác định và ngăn chặn lưu lượng truy cập lỗi
Hãy đưa ra quyết định khôn ngoan hơn dựa trên dữ liệu với adbrix và đưa sản phẩm của bạn lên tầm cao hơn!
Tháng 6 năm nay tại hai thành phố Hồ Chí Minh và Hà Nội, đội ngũ adbrix sẽ tham dự sự kiện Mobile lớn nhất Việt Nam: Vietnam Mobile Day 2019, hứa hẹn sẽ mang đến làn sóng Mobile Measurement hoàn toàn mới tới cộng đồng hội những người đam mê Kỹ thuật số ở Việt Nam. Đừng bỏ lỡ nhé!
Bài viết được sự cho phép của BBT Tạp chí Lập trình
Tóm tắt
Lập trình Cặp (Pair-Programming) là cách hai lập trình viên cùng làm việc trên chỉ một máy tính, một người lái (driver), một người làm hoa tiêu (navigator), thú vị hơn bạn tưởng tượng nhiều. Việc hoán đổi vai trò liên tục giúp cho giao tiếp thông suốt, họ cùng nhau hoàn thành công việc tốt hơn và nhanh hơn khi họ làm một mình.
Người lái tập trung vào sách lược – viết mã nguồn sạch có thể chạy được. Hoa tiêu tập trung và chiến lược – cách mã nguồn phù hợp với thiết kế chung, trường hợp kiểm thử nào sẽ “lái” mã nguồn đi đúng hướng và những tái cấu trúc nào sẽ cải thiện toàn bộ mã nguồn của chương trình.
Các cặp tự tổ chức thông qua việc chọn thành viên phù hợp nhất với tác vụ hiện thời. Trong mỗi cặp, việc hoán đổi vai trò được thực hiện sau vài tiếng để chia sẻ tầm nhìn và kiến thức.
Bài viết này được trích từ cuốn sách The Art of Agile Development (tạm dịch: Nghệ thuật Phát triển Phần mềm theo Phương pháp Linh hoạt) của tác giả James Shore và Shane Warden, được xuất bản bởi O’Reilly).
Lập trình cặp: Chúng ta giúp nhau thành công
Bạn có muốn ai đó ngồi nhìn bạn làm việc suốt ngày? Bạn có muốn phí một nửa thời gian chỉ ngồi im lìm ủ rũ xem người khác viết mã?
Tất nhiên là không. Chẳng có ai thích thế cả, đặc biệt là những người lập trình cặp.
Lập trình cặp là một trong những điều đáng chú ý đầu tiên của XP. Hai người làm việc trên chỉ một bàn phím? Thật kỳ lạ. Nhưng nó thực sự đem lại hiệu quả đáng kinh ngạc, và khi bạn đã quen thì sẽ có rất nhiều điều thú vị. Hầu như tất cả lập trình viên tôi biết, chỉ sau một tháng làm quen với lập trình cặp họ sẽ thấy thích lập trình cặp hơn làm một mình.
Tại sao cần lập trình cặp?
Chương này được đặt tên là Tư duy, và tôi giới thiệu lập trình cặp là phương pháp đầu tiên. Đó bởi vì lập trình cặp chính là để giúp bạn nghĩ tốt hơn, thông minh hơn.
Khi bạn lập trình cặp, một người viết mã (người lái). Người kia làm hoa tiêu có nhiệm vụ là ngẫm nghĩ. Khi làm hoa tiêu, đôi khi bạn nghĩ về điều người lái đang gõ (Nhưng đừng vội vàng chỉ trỏ những lỗi như kiểu thiếu dấu chấm phẩy, sẽ gây khó chịu). Đôi lúc bạn nghĩ về phần việc cần làm tiếp theo và đôi khi bạn nghĩ làm cách nào để phần đang được cài đặt đi đúng theo thiết kế tổng thể.
Việc chia ra hai vai trò như vậy giúp cho người lái tập trung vào từng dòng mã chuẩn cú pháp mà không phải lo về tổng thể chương trình, và giúp hoa tiêu có thời gian cân nhắc về hướng phát triển của chương trình mà không bị phân tâm về tiểu tiết mã nguồn cụ thể. Cùng nhau, người lái và hoa tiêu hoàn thành công việc với chất lượng cao hơn và nhanh hơn khi từng người làm việc riêng lẻ.
“Một nghiên cứu cho thấy rằng lập trình cặp tốn công sức hơn 15% so với lập trình một mình, nhưng nhanh tạo thành sản phẩm hơn
và ít lỗi hơn 15%
[Cockburn & Williams]. Tuy nhiên, mỗi đội mỗi khác nên kết quả thống kê trên chỉ nên dùng để tham khảo.“
Lập trình cặp còn củng cố những thói quen lập trình tốt. XP tin rằng việc kiểm thử liên tục và hoàn thiện thiết kế cần rất nhiều tính tự giác. Khi lập trình cặp, bạn sẽ có được sức ép tích cực từ bạn cặp để thực hiện những công việc khó khăn nhưng quan trọng trên. Bạn sẽ chia sẻ được kiến thức và thủ thuật lập trình cho toàn đội.
Bạn cũng sẽ có nhiều thời gian hơn ở trong luồng lập trình – trạng thái năng suất cao mà bạn hoàn toàn tập trung vào việc lập trình. Dù bạn làm việc cùng một người khác, nhưng luồng lập trình này vẫn bền vững và khó bị gián đoạn hơn khi lập trình một mình. Bởi đồng nghiệp sẽ ít làm phiền bạn hơn khi thấy bạn đang làm việc cùng người khác. Cho dù có bị làm gián đoạn, thì người cùng cặp sẽ giúp giải quyết vấn đề trong khi bạn vẫn tiếp tục dòng suy nghĩ của mình. Hơn nữa, khi bạn tập trung chú ý vào nói chuyện với người cùng cặp thì những tiếng ồn xung quanh sẽ tự động bị biến mất.
Nếu tất cả những điều trên chưa thuyết phục được bạn thử lập trình cặp, hãy tin tôi, lập trình cặp thực sự rất thú vị. Thêm một cái đầu sẽ giúp bạn vượt qua những vấn đề khó dễ dàng hơn nhiều. Nói chung, bạn sẽ luôn được làm việc với một đồng đội thông minh và cùng chí hướng. Thêm vào đó, nếu cổ tay bạn đau nhức do gõ quá nhiều, bạn có thể chuyển bàn phím cho đồng đội và tiếp tục làm việc không hề giảm năng suất.
Lập trình cặp như thế nào?
Tôi khuyến nghị lập trình cặp với tất cả mã nguồn sản xuất. Rất nhiều đội thực hiện lập trình cặp thường xuyên, nhưng không tuyệt đối, thấy rằng họ gặp nhiều lỗi hơn nếu lập trình đơn. Một nguyên tắc tốt là thực hiện lập trình cặp bất cứ phần nào mà bạn cần bảo trì kể cả kiểm thử và mã build ứng dụng.
Khi bạn bắt đầu làm một việc, hãy đề nghị một lập trình viên khác tham gia cùng. Nếu có ai đó đề nghị, hãy thoải mái đồng ý lập cặp cùng. Đừng bao giờ phân chia cố định các cặp, hãy lập cặp một cách tự nhiên, linh hoạt và luân chuyển các cặp trong ngày. Qua thời gian, một người sẽ lập trình cặp với tất cả mọi người trong đội. Điều này sẽ giúp cả đội gắn bó hơn và tất cả mọi người đều được chia sẻ kiến thức và các kĩ năng thiết kế.
“Có được bối cảnh tươi mới bằng cách luân chuyển cặp.”
Khi bạn cần một không khí tươi mới, hãy chuyển cặp. Tôi thường chuyển cặp khi cảm thấy chán nản hay bế tắc. Tuy nhiên luôn phải giữ lại một người đã theo phần việc từ đầu để có thể giúp người mới vào cặp nhanh chóng nắm bắt được vấn đề. Có nhiều lúc, chỉ cần giải thích vấn đề là gì cho người khác cũng giúp bạn giải quyết được vấn đề đó.
Trong lập trình cặp, dù bạn không thấy nản hay bế tắc, đổi cặp vài lần một ngày cũng tốt. Điều này sẽ giúp thông tin trong đội được thông suốt và mọi người sẽ làm việc hiệu quả hơn. Cá nhân tôi thì tôi chuyển cặp mỗi khi hoàn thành một phần việc. Nếu tôi làm một phần việc lớn, tôi chuyển cặp sau mỗi 4 tiếng.
Khi ngồi theo cặp, hãy chắc chắn rằng bạn cảm thấy thoải mái, không bị mỏi. Đặt ghế cạnh nhau, đảm bảo mỗi người có đủ khoảng trống, và có thể nhìn rõ màn hình. Khi làm người lái, hãy đặt bàn phím trước mặt bạn. Chú ý: mọi người khi lập trình theo cặp thường có xu hướng với tay đến bàn phím và chuột chứ không kéo chúng về gần (trước mặt) mình.
Những người lập trình cặp làm việc thông qua đối thoại. Dù bạn là người lái hay hoa tiêu , hãy nói tất cả những điều bạn nghĩ ra. Hãy làm từng bước thiết kế nhỏ, liên tục, tốt nhất là làm theo phát triển hướng kiểm thử và nói về những giả định của bạn, mục tiêu ngắn hạn, hướng phát triển chung, và bất kì vấn đề gì của tính năng đang cài đặt hoặc của toàn bộ dự án. Hãy hỏi khi bạn thấy mơ hồ về vấn đề gì đó. Việc thảo luận thường giúp cả bạn và người cùng cặp hiểu rõ vấn đề đó hơn.
“Khi bạn thấy một cặp có vẻ trầm (ít nói, nói nhỏ, hoặc không luân chuyển với các cặp khác) thì nó thường là dấu hiệu của khó khăn kỹ thuật.”
Bạn luôn cảm thấy mệt mỏi vào cuối ngày? Các cặp lập trình thường cảm thấy họ đã làm việc nhiều hơn và đạt hiệu quả cao hơn khi họ làm việc một mình. Hãy thực hành “Làm việc đầy năng lượng” (Energized work) để duy trì năng lượng làm việc mỗi ngày.
Lái và điều hướng
“Với thời gian làm việc theo cặp sẽ trở nên tự nhiên”
Khi mới bắt đầu, bạn sẽ cảm thấy vụng về khi làm người lái. Bạn cũng có thể cảm thấy người hoa tiêu nhìn nhận ra những ý tưởng và vấn đề nhanh hơn bạn rất nhiều. Quả thật như vậy, hoa tiêu có nhiều thời gian để nghĩ hơn người lái. Tình thế sẽ được đảo ngược khi bạn đổi vai trò, trở thành hoa tiêu. Dần dần việc làm cặp sẽ trở nên tự nhiên.
Khi điều hướng, bạn sẽ cảm thấy như muốn nhảy vào dành lấy bàn phím từ người cùng cặp. Hãy thư giãn, người lái của bạn sẽ thường đưa ra ý kiến bằng cả lời nói và mã nguồn. Người đó sẽ mắc những lỗi gõ sai hay những lỗi nhỏ, nhưng hãy cho anh ý chút thời gian để tự sửa lại. Hãy dùng trí lực của bạn để nghĩ về bức tranh lớn hơn. Những kiểm thử nào khác bạn cần phải viết? Làm thế nào để đoạn mã phù hợp với phần còn lại của hệ thống? Có sự trùng lặp nào cần loại bỏ không? Mã có thể rõ ràng hơn được không? Thiết kế tổng thể có thể được tốt hơn không?
Nhiệm vụ của hoa tiêu là giúp người lái làm việc hiệu quả hơn. Hãy nghĩ về những điều xảy ra tiếp theo và chuẩn bị những đề xuất. Khi tôi điều hướng, tôi thường giữ một thẻ chỉ mục trước mặt tôi. Thay vì làm gián đoạn người bạn cầm lái khi tôi nghĩ về một vấn đề, tôi viết những ý tưởng của tôi lên thẻ chỉ mục và chờ đến lúc nghỉ để thảo luận. Vào cuối phiên làm việc cặp, tôi xé tấm thẻ và bỏ nó đi.
Tương tự như vậy, khi một câu hỏi phát sinh, hãy dành một chút thời gian để tìm kiếm câu trả lời trong khi người lái đang làm việc. Một số nhóm dùng thêm máy tính sách tay cho mục đích này. Nếu bạn cần nhiều hơn một vài phút, hãy cùng người lái tìm kiếm giải pháp. Đôi khi cách tốt nhất để làm là tách riêng ra, tìm kiếm song song với nhau và thường xuyên chia sẻ với nhau những gì học được. Những khung giải pháp là một cách tiếp cận hiệu quả.
Khi ghép cặp, hãy thường xuyên chuyển đổi vai trò cho nhau ít nhất sau mỗi 30 phút, có thể là sau vài phút. Khi bạn điều hướng và thấy rằng cần bảo người lái phải bấm phím nào đó, hãy tự mình bấm luôn phím đó. Nếu khi lái bạn cần nghỉ ngơi một chút, hãy đưa bàn phím cho hoa tiêu.
Thủ thuật lập trình cặp
Làm việc theo cặp với bất cứ thứ gì bạn cần bảo trì
Hãy để các cặp hình thành tự nhiên hơn là bị gán cố định
Hãy chuyển đổi đối tác khi bạn cần một không khí tươi mới
Tránh cặp với cùng một người trong hơn một ngày
Ngồi thoải mái, cạnh nhau
Viết mã thông qua đối thoại. Hãy hợp tác chứ đừng chỉ trích
Người lái và hoa tiêu thường xuyên hoán đổi vai trò cho nhau
Không gian lập trình cặp
Để lập trình cặp thoải mái, không gian làm việc tốt là thiết yếu. Bạn cần nhiều không gian để hai người ngồi cạnh nhau được thoải mái. Những nơi làm việc ở góc phòng nhỏ điển hình sẽ không hiệu quả. Chúng không thoải mái và một người phải ngồi sau người kia, gây ra rào cản tâm lý cũng như vật lý ngăn cản sự cộng tác.
Bạn không cần đồ nội thất bóng bẩy để lập trình cặp tốt. Thứ tốt nhất tôi từng thấy chỉ là những chiếc bàn gấp đơn giản được tìm thấy tại bất kì cửa hàng đồ văn phòng tốt nào. Chúng nên dài khoảng 1,8 mét, để hai người có thể ngồi thoải mái cạnh nhau, và cao ít nhất 1,2 mét. Mỗi bàn cần một máy tính mạnh mẽ chuyên dùng cho lập trình. Mỗi máy tính nên có hai bộ bàn phím và chuột để tiện cho mỗi người trong cặp.
Nên có màn hình lớn để cả 2 người có thể nhìn thấy rõ ràng. Một số nhóm hiển thị lên hai màn hình giống nhau, giúp dễ nhìn hơn một chút, nhưng có thể làm bạn chỉ sai màn hình khi thảo luận với nhau. Một số nhóm khác lại thích hiển thị một màn hình desktop lên hai màn hình LCD.
Những thử thách khi lập trình cặp
Lập trình theo cặp ban đầu có thể không được thoải mái, bởi cách làm việc này yêu cầu bạn phải có tinh thần hợp tác nhiều hơn cách mà bạn quen làm. Điều này là tự nhiên và thường sẽ mất đi sau một hoặc hai tháng, nhưng bạn phải đối mặt với một vài thử thách.
Sự thoải mái
Hãy ghi nhớ rằng: lập trình cặp không vui chút nào nếu bạn không thoải mái. Khi bạn ngồi xuống làm việc, điều chỉnh vị trí và thiết bị sao cho bạn cảm thấy thoải mái. Dọn rác trên bàn làm việc và hãy chắc chắn có đủ không gian cho chân và đầu gối của bạn.
Một vài người (như tôi) cần rất nhiều không gian riêng. Những người khác lại thích ngồi gần hơn. Khi bạn bắt đầu ghép cặp, hãy thảo luận về nhu cầu không gian cá nhân của bạn và đối tác của bạn.
Tương tự như vậy, không thể không nhắc tới vấn đề vệ sinh cá nhân. Nhớ rằng những hương vị mạnh như cà phê, tỏi, hành, thức ăn cay có thể dẫn tới hơi thở hôi. Để tránh xảy ra rắc rối, hãy cùng nhau quyết định cách góp ý về những thói quen cá nhân một cách tôn trọng.
Chênh lệch về trình độ
Lập trình theo cặp thường là sự hợp tác giữa những người có trình độ tương đương nhau, nhưng thỉnh thoảng một lập trình viên cao cấp, nhiều kinh nghiệm sẽ cặp với một người ở trình độ thấp hơn. Thay vì xem mối quan hệ này như sinh viêngiáo viên, hãy lấy lại sự cân bằng ngang hàng bằng cách tạo ra cơ hội cho cả hai người để học tập. Ví dụ, nếu biết bạn được cặp với một lập trình viên còn non kém kinh nghiệm, bạn có thể đề nghị người đó nghiên cứu về một chủ đề mà không ai khác biết, chẳng hạn các công việc bên trong của một thư viện mà nhóm phụ thuộc vào. Hãy cho tất cả mọi người một cơ hội trở thành chuyên gia.
Phong cách giao tiếp
Những người lái mới thỉnh thoảng gặp khó khăn trong giao tiếp với người hoa tiêu, họ có thể chiếm bàn phím tự gõ mã theo ý họ và làm mất đi sự giao tiếp trong cặp. Để thực hành giao tiếp và chuyển đổi vai trò trong lập trình cặp, hãy thử lập trình cặp kiểu bóng bàn (ping-pong pairing). Khi lập trình cặp kiểu bóng bàn, một người A viết một kiểm thử. Người B sẽ viết mã để vượt qua kiểm thử rồi viết một kiểm thử mới cho người A . Người A viết mã để vượt kiểm thử rồi lại viết một kiểm thử mới. Quá trình như vậy được lặp đi lặp lại như khi chơi bóng bàn.
Ngược lại của giao tiếp quá ít là giao tiếp quá nhiều, những sự giao tiếp không cần thiết. Những lời phê bình thẳng thắn về mã nguồn và thiết kế là rất quí báu, nhưng ban đầu ta sẽ khó mà chấp nhận được chúng. Mỗi người có một độ nhạy cảm khác nhau, vì vậy hãy chú ý tới cách đối tác của bạn tiếp nhận những lời nhận xét của bạn như thế nào. Hãy cố chuyển những câu khẳng định (ví dụ: “Phương thức này quá dài”) thành câu hỏi hay lời gợi ý (“Chúng ta có thể làm phương thức này ngắn hơn không?” hoặc “Chúng ta có nên đẩy khối mã này ra thành một phương thức mới hay không?”). Hãy giữ một thái độ hợp tác để cùng giải quyết vấn đề.
Công cụ và phím tắt
Ngay cả khi bạn không là nạn nhân trong cuộc chiến bất tận giữa trình soạn thảo vi và emacs, bạn cũng có thể thấy khó chịu với các thiết lập trong công cụ của người cùng cặp. Hãy cố gắng chuẩn hóa một thiết lập nào đó. Một vài nhóm thậm chí còn tạo cả một bản chuẩn và đặt nó trong quản lý phiên bản. Khi bạn thảo luận về các quy chuẩn lập trình, hãy thảo luận cả vấn đề này nữa.
Hỏi và đáp về lập trình cặp
Liệu có lãng phí không khi cần tới hai người làm công việc của một người?
Trong lập trình theo cặp, hai người không thực sự chỉ làm công việc của một người. Mặc dù chỉ có một bàn phím được sử dụng nhưng lập trình có nhiều công việc khác ngoài gõ mã. Ward Cunningham đã nói: “Nếu bạn không nghĩ một cách cẩn thận, bạn có thể nghĩ rằng lập trình chỉ là gõ những câu lệnh của một ngôn ngữ lập trình.” Trong lập trình theo cặp, một người sẽ lập trình còn người kia nghĩ về những thứ xa hơn, về những vấn đề có thể phát hiện sớm, và chiến lược.
Nếu bạn cần tìm hiểu sâu hơn, [Williams] có một bộ nghiên cứu về lập trình theo cặp. Hãy nhớ rằng những biến thể trong phát triển phần mềm làm nó rất khó để thực hiện những nghiên cứu quy mô lớn. Đôi khi cách tốt nhất để biết thứ gì đó có hoạt động tốt cho nhóm của bạn hay không là hãy thử nó.
Làm sao để thuyết phục nhóm hay công ty tôi thử lập trình cặp?
Hãy xin được thử nghiệm lập trình cặp. Dành khoảng một tháng để tất cả mọi người làm việc theo cặp trên tất cả các mã nguồn sản phẩm. Hãy cố gắng thử nghiệm đủ một tháng, cho dù lập trình cặp thường khó làm và khiến bạn không thoải mái trong vài tuần đầu tiên.
Đừng nên chỉ xin phép quản lý, hãy chắc chắn tất cả các thành viên trong nhóm của bạn cũng cảm thấy thích thú khi thử lập trình cặp nữa. Những lập trình viên duy nhất tôi biết không thích lập trình cặp sau khi thử trong một tháng là những người bị ép buộc phải làm.
Chúng tôi có phải lập trình cặp mọi lúc không?
Đây là điều mà cả nhóm của bạn nên cùng quyết định. Trước khi quyết định, hãy thử làm việc theo cặp trong tất cả các mã nguồn sản phẩm (mọi thứ bạn cần phải bảo trì) trong một tháng. Ban có thể sẽ thấy thú vị hơn mong đợi.
Bất chấp những quy định, bạn vẫn sẽ làm ra những đoạn mã mà bạn không phải phải bảo trì (Khung giải pháp là một ví dụ). Những cái này có thể được hưởng lợi từ nghiên cứu cá nhân.
Nếu bạn thấy chán khi lập trình cặp, hãy xem bạn có thể làm cho thiết kế ít lặp lại hơn không.
Một vài tác vụ cứ lặp đi lặp lại đến nỗi mà không cần thiết phải động não thêm.Tuy nhiên, trước khi từ bỏ lập trình cặp, hãy xem tại sao thiết kế của bạn lại yêu cầu quá nhiều sự lặp lại. Nó có thể là dấu hiệu của một lỗ hổng thiết kế. Hoa tiêu nên sử dụng thêm thời gian để nghĩ về việc cải tiến thiết kế và thảo luận nó với cả nhóm.
Làm sao tôi có thể tập trung khi mà luôn có ai đó cứ nói chuyện với tôi?
Khi điều hướng, nếu bạn gặp khó khăn để hiểu các bước tiếp theo người lái định làm, hãy yêu cầu người lái nói ra suy nghĩ của họ.
Là người lái, đôi khi bạn có thể thấy rằng mình đang mất tập trung. Hãy để người điều hướng biết, họ có thể đưa ra gợi ý giúp bạn giải quyết vấn đề. Cũng có thể, bạn chỉ cần một vài khoảnh khắc yên tĩnh để tập trung lại.
“Nếu bạn khó tập trung, hãy thử thực hiện các bước nhỏ hơn.”
Nếu bị mất tập trung liên tục, bạn có thể đã làm theo các bước quá lớn. Hãy sử dụng TDD (Test-Driven Development) và làm theo các bước rất nhỏ (baby step). Dựa vào người điều hướng của bạn để theo dõi những gì bạn cần làm (nói với cô ấy nếu bạn có một ý tưởng, cô ấy sẽ viết nó ra) và chỉ tập trung vào vài dòng mã cần phải làm để vượt qua kiểm thử.
Nếu bạn đang làm việc với một kĩ thuật mà bạn không hoàn toàn hiểu, dành vài phút để làm việc với một khung giải pháp. Bạn và người cùng cặp của bạn có thể cùng làm hoặc làm riêng.
Làm gì nếu chúng tôi bị lẻ một người ?
Người lập trình viên bị lẻ ra đó có thể làm những công việc khác không liên quan đến mã nguồn sản phẩm. Anh ta có thể nghiên cứu kỹ thuật mới, hoặc nghiên cứu sâu hơn về công nghệ mà nhóm đang dùng. Hoặc anh ta có thể bắt cặp cùng với một khách hàng hoặc kiểm thử viên để xem xét chương trình, “đánh bóng” chương trình hoặc làm kiểm thử khám phá. Hoặc anh ta cũng có thể làm batman của nhóm (trong một nhóm XP, batman là người xử lý những yêu cầu trợ giúp hoặc yêu cầu đột xuất của khách hàng, thuyết phục họ dời yêu cầu đột xuất đó sang phân đoạn sau, xem thêm ở “Iteration Planning” ).
Thường thì lập trình viên bị lẻ ra dùng thời gian để xem lại thiết kế tổng thể để hiểu rõ hơn nó hoặc nghĩ cách cải thiện những phần chưa ổn. Nếu có nhiều việc tái cấu trúc cần làm, người lập trình viên lẻ có thể đảm nhận việc này.
Nếu nhóm chỉ có 2 hay 3 người, có nên lập trình cặp liên tục?
Thậm chí một ông thánh cũng có thể làm bạn phát cáu nếu bạn cứ phải cặp với ông ta ngày này qua ngày khác. Bạn phải tự mình quyết định khi nào thì lập trình cặp và khi nào bạn cần thời gian làm việc một mình. Nếu bạn thấy ổn nhưng cặp của bạn lộn xộn dần, đừng cố quá, hãy nghỉ ngơi một chút.
Tôi đã từng lập trình cặp với một người trong 3 tháng liền làm một dự án hai người. Tôi nghĩ việc chúng tôi có một văn phòng rộng và một cái bàn to rất hữu ích: nó giúp chúng tôi không gian để di chuyển vòng vòng xả căng thẳng. Chúng tôi còn có một cái tủ lạnh mini với đầy đồ ăn ở trong.
Thậm chí khi có những điều kiện thoải mái như vậy, tôi vẫn có những lần phải phát cáu lên.
Có lẽ điều quan trọng giúp tôi có thể lập trình cặp với cùng một người lâu như vậy là nhờ người cùng cặp với tôi là người rất dễ tính và không để tâm đến những lần tôi phát cáu đó.
Quá tập trung vào công việc và quên mất việc chuyển cặp, làm cách nào để chuyển cặp thường xuyên hơn?
Thực tế, thời điểm tốt nhất để đổi cặp và có được không khí làm việc tươi mới là khi bạn cảm thấy bế tắc hoặc “ngán”.
Một vài đội dùng đồng hồ báo giờ để chuyển cặp sau một khoảng thời gian định trước. Báo cáo của Belshee cho thấy rằng chuyển cặp sau mỗi 90 phút đem lại hiệu quả tốt. Mặc dù việc tạo thói quen chuyển cặp là rất tốt, nhưng hãy chắc chắn là tất cả mọi người đều muốn vậy (Có thể có ai đó không muốn chuyển cặp mà muốn tiếp tục làm việc cặp với người cũ để giải quyết nốt vấn đề sắp xong chẳng hạn).
Làm thế nào để lập trình cặp từ xa?
Bạn có thể dùng tai nghe và phần mềm chia sẻ màn hình desktop như VNC hay NetMeeting để lập trình cặp từ xa. Tôi có nghe nói đến những đội đã dùng hai máy tính nhưng chia sẻ cùng màn hình với nhau cùng với chương trình VoIP. Khi tôi thử theo cách này, tôi thấy rằng nó khá tệ. Các đội XP thường ngồi cùng nhau, vì vậy việc lập trình cặp từ xa thường không cần thiết.
Những lợi ích đáng kinh ngạc của lập trình cặp
Khi bạn đã lập trình cặp thuần thục, bạn sẽ thấy mình hết sức tập trung vào công việc và làm việc với bạn cùng cặp. Bạn sẽ ít bị gián đoạn và xao nhãng hơn. Khi bị ai đó gián đoạn thì sẽ có một người giải quyết vấn đề còn người kia tiếp tục công việc. Sau gián đoạn, bạn có thể trở lại với công việc ngay lập tức. Đến cuối ngày, bạn sẽ thấy thoả mãn dù mệt mỏi. Bạn thích thú được làm việc tập trung và thân thiện với bạn cùng cặp.
Toàn nhóm có được mã chất lượng cao hơn hẳn. Nợ kỹ thuật (technical debt) giảm. Kiến thức thông suốt trong nhóm, giúp nâng cao trình độ của mỗi người và giúp thành viên mới nhanh chóng hoà nhập vào nhóm.
Chống chỉ định
Lập trình cặp yêu cầu một môi trường làm việc thoải mái. (tham khảo các thiết kế “Sit Together” ở chương 6). Nếu không gian làm việc của bạn không cho phép các cặp ngồi cạnh nhau một cách thoải mái, hoặc là thay đổi không gian làm việc hoặc là đừng lập trình cặp nữa.
Tương tự như vậy, nếu đội của bạn không ngồi cùng nhau, lập trình cặp có thể mất tác dụng. Việc lập trình cặp từ xa thì không thể bằng được khi ngồi cùng nhau.
Một lý do khác để không lập trình cặp khi lập trình viên không thích ứng được. Lập trình cặp là một sự thay đổi lớn về phong cách lập trình và bạn có thể gặp phải vấn đề không tương thích. Tôi thường giải quyết vấn đề này bằng cách yêu cầu mọi người cố gắng thử lập trình cặp trong một hoặc hai tháng trước khi đưa ra quyết định cuối cùng. Nếu họ vẫn không thể thích ứng được, tốt nhất là không nên áp dụng lập trình cặp nữa thay vì cố gắng ép buộc.
Các giải pháp thay thế
Lập trình cặp là một phương pháp rất mạnh mẽ. Nó làm giảm các thiếu sót, cải thiện chất lượng thiết kế, chia sẻ kiến thức giữa các thành viên trong nhóm, tăng tính kỉ luật, giảm phiền nhiễu mà không bị giảm năng suất. Nếu bạn không thể lập trình cặp, bạn cần phương pháp thay thế.
Thanh tra mã nguồn một cách chính thống có thể giảm thiếu sót, cải thiện chất lượng, tăng tính kỉ luật. Tuy nhiên, theo kinh nghiệm của tôi, các lập trình viên có vấn đề bao gồm cả sự kiểm tra trong lịch làm việc của họ, ngay cả khi họ đang ủng hộ nó. Lập trình cặp dễ dàng hơn để làm một cách nhất quán, và nó cung cấp nhiều phản hồi nhanh hơn là sự kiểm duyệt theo lịch trình. Nếu bạn muốn sử dụng những kiểm duyệt ở nơi đang lập trình cặp, hãy thêm một số cơ chế hỗ trợ để giúp chúng được thực hiện.
Kiểm duyệt tự nó không có khả năng chia sẻ kiến thức kỹ càng như việc sở hữu mã tập thể đòi hỏi. Nếu bạn không thể lập trình theo cặp, hãy xem xét tránh việc sở hữu mã tập thể, ít nhất lúc đầu.
Nếu bạn vẫn muốn có việc sở hữu mã tập thể, bạn cần một cơ chế thay thế cho việc chia sẻ kiến thức về trạng thái của mã nguồn cơ sở. Tôi đã thành lập các nhóm nghiên cứu thường xuyên nơi mà các lập trình viên gặp nhau hàng ngày trong khoảng 30 phút để xem xét và thảo luận về thiết kế.
Tôi không biết bất kì phương pháp nào giúp giảm những thiết sót tốt như lập trình cặp. Tuy nhiên, tôi nhận thấy rằng mình không chịu đựng được nhiều phiền nhiễu khi đang mệt. Khi không lập trình cặp, hãy quan tâm nhiều hơn đến tầm quan trọng của nhiệt huyết trong công việc.
Đến năm 2020, sẽ có khoảng 5,5 tỷ thiết bị di động trên toàn thế giới, điện thoại thông minh dần trở thành vật không thể thiếu đối với đời sống hàng ngày của người Việt. Theo các báo cáo trong nước gần đây chỉ ra rằng, có khoảng 45% người Việt kiểm tra điện thoại ngay khi tỉnh dậy trong 5 phút và dành thời gian trung bình 2 tiếng một ngày cho smartphone.
Hơn thế nữa, “xóa 3 app tải về 5 app” là con số trung bình của 72% người Việt có smartphone trong mỗi tháng. Những con số trên chứng minh cho tính khả quan của sự phát triển không ngừng của điện thoại thông minh và những công nghệ di động kèm theo. Có thể nói chuyển dịch số (digital transformation) với sức phủ rất lớn đang đặt ra hai kịch bản cho các doanh nghiệp phải lựa chọn: hoặc chết, hoặc phát triển vượt bậc nếu biết tận dụng lợi thế công nghệ. Từ đó cho thấy tầm quan trọng của Mobile và digital hóa, các doanh nghiệp phải nghĩ về sự chuyển mình trong năm 2019.
Đâu là chìa khóa thành công cho doanh nghiệp 2019?
Với tầm quan trọng của công nghệ mobile, doanh nghiệp có thể tăng tính hiệu quả trong việc đồng nhất quản lý hệ sinh thái của mình, giảm chi phí bảo trì nâng cấp của bên thứ 3. Xu hướng mới này khiến các thương hiệu đều “đứng ngồi không yên” với những trăn trở làm sao để ứng dụng các phương thức digital transformation cho doanh nghiệp của mình. Vietnam Mobile Day 2019 sẽ bật mí những câu
Xu hướng Mobile Payment đã trở thành phương thức thanh toán phổ biến tại nhiều quốc gia phát triển, thúc đẩy các giao dịch thanh toán cho toàn thị trường. Với giá trị chi tiêu của người dân chiếm tới hơn 80% tổng số giao dịch hàng ngày với những tiện nghi tuyệt vời mà nó mang lại như: nhanh chóng, chính xác và hạn chế chi phí. Trong năm vừa qua, các thanh toán qua mobile tăng đến 161%. Một thực tế cho thấy, việc các ứng dụng đặt xe và đặt thức ăn đã góp phần không nhỏ cho sự tăng trưởng vượt bậc này.
Tự động hóa quy trình tự động (Robotics Process Automation – RPA) đã trở thành một giải pháp rất “thời thượng” trong suốt năm 2018. RPA thường được đặt trong nhóm với Trí tuệ nhân tạo (Artificial Intelligence – AI) và Học máy (Machine Learning – ML) và sự phát triển của tổ hợp này đã bùng nổ được một thời gian. Tuy nhiên, khi được tách riêng ra, RPA được dự đoán sẽ có một sự tăng trưởng đáng kinh ngạc như một thị trường độc lập.
Theo báo cáo của Forrester, thị trường RPA trị giá khoảng 250 triệu đô la vào năm 2016, nhưng ước tính sẽ tăng lên 2,1 tỷ đô la vào năm 2021. Chỉ riêng trên G2 Crowd, số lượng và tần suất truy cập vào trang danh mục RPA đã tăng đáng kể trong suốt năm 2018. Từ thời điểm danh mục được thêm vào tháng 2 năm 2018 đến cuối tháng 10 năm 2018, lưu lượng truy cập không phải trả tiền cho trang danh mục RPA đã tăng gần mười lần và hiện là hạng mục cao thứ mười về lưu lượng truy cập miễn phí trên tất cả G2 Crowd, điều đó có nghĩa là người mua đang rất tích cực tìm kiếm các giải pháp tự động hóa.
Sẽ có khoảng 20 tỷ thiết bị IOT được sinh ra vào năm 2020, có lẽ đây sẽ là một con số gây ấn tượng cho bất kỳ tín đồ công nghệ nào. IOT sẽ được gắn liền như hình với bóng với chiếc điện thoại thông minh của từng cá nhân. Cuộc đua sẽ trở nên nóng bỏng hơn giữa những nhà cung cấp, có đến 22% các doanh nghiệp khảo sát tin rằng, IOT sẽ là một trong những mũi nhọn đáng đầu tư nhất trong năm nay. Security, Edge computing, Automation và nhiều công nghệ hấp dẫn hơn nữa sẽ được giới thiệu một cách chi tiết nhất tại sự kiện năm nay.
Một trong những hội nghị công nghệ lớn nhất Việt Nam diễn ra hằng năm – Vietnam Mobile Day 2019 sắp trở lại
Một trong những xu thế về công nghệ được mong chờ sẽ làm mưa làm gió trong năm 2019 là công nghệ mạng dữ liệu không dây 5G. Không chỉ có tốc độ đường truyền nhanh gấp nhiều lần so với 4G LTE, 5G còn có thể cho phép số lượng thiết bị kết nối gấp 100 lần trong 1 đơn vị diện tích. Theo một cuộc khảo sát của Công ty Ericsson, 92% các chuyên viên trong số 100 nhà điều hành viễn thông toàn cầu đồng ý rằng 5G sẽ mở đường cho sự nổi lên của các ứng dụng công nghệ. Đặc biệt hơn, mạng dữ liệu 5G sẽ giúp thiết lập Internet vạn vật (IoT) trở thành một phần không thể thiếu trong cuộc sống, thông qua việc đặt nền móng để phát huy hết toàn bộ tiềm năng của nó. Gartner dự đoán sẽ có 20.4 tỷ thiết bị IoT được đưa vào sử dụng trước năm 2020 và con số này sẽ còn tiếp tục gia tăng.
Nắm bắt được xu thế công nghệ di động nổi bật, VIETNAM MOBILE DAY 2019 được tổ chức bởi TopDev sẽ có hơn 100 chủ đề nóng nhất hiện nay được triển khai xuyên suốt đảm bảo mang đến những chuyên đề không chỉ về khía cạnh công nghệ, kỹ thuật trên nền tảng di động mà còn là một lượng lớn kiến thức, kỹ năng thực tiễn liên quan đến 6 lĩnh vực Fintech, Blockchain, Mobile App & Game, Digital & Mobile Marketing và AI/Machine Learning do các chuyên gia đầu ngành tham gia chia sẻ với mong muốn đem ngành công nghệ Việt Nam đến gần hơn với tiêu chuẩn thế giới.
Trong năm vừa qua, với sự góp mặt của Microsoft, Google Play, Facebook, Lazada, etc tạo nên một thành công vang dội cho sự kiện hứa hẹn chuỗi sự kiện sắp tới sẽ tiếp tục có sự tham gia của các tập đoàn công nghệ lớn này. Sự kiện mang lại một sân chơi hấp dẫn, phong phú, thu hút hơn 9.000 người tham dự; với hơn 550 doanh nghiệp lớn nhỏ hoạt động trong ngành công nghệ thông tin và hơn 80 diễn giả tham gia chia sẻ, chắc chắn đây sẽ là một bữa tiệc thịnh soạn dành cho cộng đồng lập trình, doanh nghiệp và khởi nghiệp quan tâm đến lĩnh vực công nghệ.
THỜI GIAN & ĐỊA ĐIỂM DIỄN RA SỰ KIỆN
TP. Hồ Chí Minh: 06/06/2019 tại Grand Palace, 142/18 Cộng Hòa, P.4, Q. Tân Bình, Tp.HCM
TP. Hà Nội: 14/06/2019 tại CTM Palace 131 Nguyễn Phong Sắc, Dịch Vọng Hậu, Cầu Giấy, Hà Nội
Ý tưởng xây dựng Progressive Web App (viết tắt là PWA) không phải là mới, được Google giới thiệu lần đầu vào năm 2015 với mục đích mang lại thật nhiều lợi ích cho cả người dùng và các nhà phát triển.
Sau nhiều quá trình cố gắng, các engineers Pinterest đã xây dựng Progressive Web App thành công với thiết kế trải nghiệm người dùng tuyệt vời trong trình duyệt trên mobile.
Và đây là kết quả họ đã đạt được sau khi xây dựng thành công Progressive Web App:
Qua kết quả trên thấy được, thời gian sử dụng ứng dụng đã tăng lên 40%, doanh thu từ quảng cáo đã tăng đến 44%, số lượng click vào quảng cáo đã đạt đến 50%, và số lượng tương tác đã tăng đến 60%.
Trong khi đó ở native app và phiên bản web trên desktop thì tốc độ tăng trưởng thấp hơn rất nhiều.
Từ kết quả trên ta thấy được 1 điều, khi trải nghiệm người dùng tốt sẽ dẫn đến lượng tương tác của người dùng tăng lên, và kéo theo doanh thu cũng tăng theo.
Vậy chúng ta cùng tìm hiểu xem các kĩ sư Pinterest đã xây dựng Progressive Web App lớn nhất thế giới như thế nào nhé.
Trước khi bắt đầu, cùng điểm qua xem Progressive Web App nó là gì đã nhé.
Đầu tiên mình nhấn mạnh là Progressive Web App không phải là 1 web framework hay 1 công nghệ gì mới. Nó là 1 sự kết hợp giữa lập trình web và lập trình ứng dụng di động.
Nó sẽ giúp cho chức năng trên web tương tự như chức năng trên mobile. Tương tự đến mức mà người dùng khó phân biệt được mình đang dùng trên trình duyệt hay là đang dùng trên native app.
Progressive Web App sẽ làm được những gì?
Tải nhanh: tốc độ tải dữ liệu cực nhanh, áp dụng cơ chế cache sẽ giúp cho ta có thể xem được dữ liệu khi mà đang offline.
Trải nghiệm người dùng tốt: Vì giao diện dùng trên Progressive Web App khá giống với trên native app. Nên sẽ giúp trải nghiệm người dùng tốt hơn. Ví dụ có thể gửi được thông báo, rồi có thể sử dụng quyền truy cập đến thiết bị như native app.
Tại sao Pinterest quyết định sử dụng Progressive Web App?
Qua dữ liệu thống kê thấy được, 80% tổng số lượng người dùng Pinterest đang sử dụng trình duyệt browser trên mobile thay vì sử dụng ứng dụng native app.
Mặc dù số lượng người dùng download app cũng tăng lên theo ngày nhưng mà cũng có không ít số lượng review không tốt. Đây là 1 ví dụ:
Cách đây 2 năm (năm 2017), bên Pinterest đã tập trung build 1 đội viết lại trang web trên mobile sử dụng Progressive Web App.
Có 2 lí do khiến Pinterest đầu tư rất nhiều vào mobile web.
Đầu tiên là vì người dùng. Progressive Web App sẽ giúp những người có mạng internet tốc độ thấp hay gói dữ liệu hạn chế có khả năng trải nghiệm tốt hơn. Với hơn 1 nửa người dùng không ở US, việc xây dựng 1 mobile web tốt, tốc độ tải trang nhanh, tiết kiệm băng thông sẽ giúp Pinterest dễ truy cập hơn trên toàn cầu, và cuối cùng sẽ giúp trải nghiệm người dùng tốt hơn.
Lí do thứ 2 là dựa trên dữ liệu (data-driven). Do trải nghiệm người dùng trên native app không được tốt nên có 1 tỉ lệ rất nhỏ người dùng do không authen được nên đã chuyển sang dùng mobile web. Nhưng số lượng người dùng trên native app vẫn lớn hơn và có độ tương tác tốt hơn rất nhiều so với trên mobile web, và để chuyển đổi người dùng từ native app sang mobile web không phải là việc dễ dàng gì. Nhưng Pinterest nghĩ họ có thể làm tốt hơn.
Vậy kĩ sư Pinterest đã làm nó như thế nào? Vào tháng 7/2017, Pinterest đã thành lập ra 1 nhóm kết hợp từ các engineer từ nền tảng web và growth teams. Trong nội bộ Pinterest gọi nó là Project Duplo.
Vào thời điểm đó, mobile web chỉ chiếm khoảng 10% tổng số lượt signup (đăng kí tài khoản). Cùng thời điểm thì website trên nền tảng desktop đã tăng gấp 5 lần.
Mốc thời gian:
Tháng 7/2017: Bắt đầu dự án Duplo
Tháng 8/2017: Launch 1 trang web mới trên mobile cho 1 tỉ lệ phần trăm người dùng đã logged-in.
Tháng 9/2017: Ship trang web mới trên mobile cho toàn bộ người dùng đã logged-in vào
Tháng 1/2018: Launch 1 trang web mới trên mobile cho tỉ lệ phần trăm của người dùng đã logged-out
Tháng 2/2018: Ship trang web mới trên mobile cho toàn bộ người dùng đã logged-out.
Lí do mà các kĩ sư Pinterest có thể hoàn thành xong 1 phiên bản trên mobile web chỉ mất có 3 tháng là do họ có sử dụng 1 open source do chính họ tạo ra có tên là Gestalt.
Ở Pinterest họ đang sử dụng React cho tất cả web development. Các bộ phận trong Gestalt được xây dựng để bao gồm các design language, giúp dễ dàng tạo ra các trang khá đẹp mà không phải lo lắng về CSS.
Gestalt tạo ra 1 bộ các component dành riêng cho thiết bị di động để tạo ra các trang có khoảng cách nhất quán với toàn bộ trang. Điều đó giúp cho quá trình xây dựng website trở nên nhanh và đơn giản hơn.
Ngoài Gestalt thì Pinterest cũng sử dụng 1 số thư viện khác nữa như React, Reac-router v4, redux, redux-thunk, Reac -redux, normalizr, reselect, Flow và prettier .
Làm thế nào để làm tốc độ tải trang được nhanh hơn?
Cải thiện hiệu năng web luôn là vấn đề được quan tâm, bởi vì nó ảnh hưởng rất lớn đến mức độ tương tác của người dùng đến hệ thống. Đặc biệt với những người có tốc độ mạng kém hay bị giới hạn. Chẳng ai thích thú gì khi phải load những trang khá nặng mà mạng đang dùng thì khá chậm phải không nào.
Sau khi tối ưu, Pinterest đã giảm kích thước file Javascript từ 490kb xuống còn 190kb. Việc này đạt được nhờ code-splitting ở tầng route, đặc biệt dùng component <Loader> sẽ giúp các bạn làm được điều đó.
Ngoài ra nhờ việc sử dụng hệ thống preloading được đặt ở phía client side đã giúp cho tốc độ tải trang được nhanh hơn, làm trải nghiệm người dùng được tốt hơn.
Chỉ trong 1 năm, phía mobile web đã có trên 600 file javascript, và tất cả nó đã được build vào 1 file được gọi là file bundle. Điều này sẽ rất khó trong việc đo lường để tối ưu hiệu năng.
Do đó, Pinterest đã phân tán các file javascript đó trên các trang web con dạng *.pinimg.com và đảm bảo rằng các dependencies trong mobile web luôn luôn được clean.
Nhìn vào hình ảnh trên chúng ta thấy được là các file js đang được nằm phân tán trên các website khác của pinterest (s.pinimg.com) và những file này đều được trả về từ Service Worker.
Để file bundle không vượt quá giới hạn cho phép, phía Pinterest đã tạo ra những graph để report các file bundle đã được build và sẽ thông báo khi có file nào vượt quá kích thước cho phép.
Cái thứ 2 mà Pinterest đã làm là đã customize eslint rule để không cho phép import những files hay directories mà có thể là nguyên nhân gây “phình” to file bundle. Ví dụ như mobile web sẽ không cho phép import từ những file trên desktop web. Đương nhiên họ sẽ có 1 thư mục dùng chung cho cả 2 mobile web với desktop web.
Và đây là kết quả khi họ tối ưu tốc độ load trang web:
Sau khi đã tối ưu được tốc độ load trang, thì điều tiếp theo họ nghĩ là làm thế nào để hiển thị dữ liệu được nhanh hơn.
Như chúng ta đã biết, với React thì cái driver lớn nhất mà ảnh hưởng đến hiệu năng phía client side đó chính là redux store (1 trong những component có thể giúp cho quá trình thay đổi route 1 cách tức thì). Xem thêm về connect React-Redux.
Ví dụ như màn hình list pins đang hiển thị hình ảnh vs title của pin. Từ màn hình list pins, chúng ta click vào 1 pin để xem chi tiết.
Khi đó dữ liệu về ảnh với title của pin ở màn hình list sẽ được mang sang màn hình detail pin để hiển thị ngay lập tức.
Đồng thời, Pinterest sẽ gửi thêm 1 request để lấy thêm dữ liệu về pin (như thông tin về owner của pin, description của pin, số lượng follow …). Khi đó người dùng có cảm giác tốc độ hiển thị dữ liệu khá nhanh, điều đó làm cho trải nghiệm người dùng cũng được tốt hơn.
Ngoài ra “trái tim” của trang web mới này đó là nó support cả phần app shell, add đến homescreen, push notifications and asset caching.
Service Worker sẽ cache lại server-rendered đối với từng người dùng cụ thể, và phục vụ cho lần page load tiếp theo.
Đặc biệt Pinterest đã rất “biết ơn” Apple đã tích hợp Service Worker trên Safari, để giúp cho người dùng có trải nghiệm tốt hơn như trên native app.
Kết quả đạt được
Bây giờ đến phần mà các bạn mong chờ: đó là những con số.
Active users hoạt động trên mobile web đã tăng lên 103% so với năm trước, với 156% ở Brazil và 312% ở India.
Thời gian sử dụng mobile web đã tăng lên đến 296%
Số lượng pin đã tăng lên 401%
Số lượng người dùng muốn save Pin đến board tăng đến 295%
Và đặc biệt hơn, số lượng login đã tăng lên 370%, số lượng signup đã tăng 843% trên 1 năm.
Thời đại công nghệ ngày nay, quả thực trải nghiệm người dùng rất quan trọng, nó quyết định đến sự sống còn của dịch vụ.
Nếu bạn nào đang có ý định phát triển Progressive Web App thì hi vọng qua bài này sẽ giúp 1 phần nào đó.
Ruby On rails là một Framework cho phép phát triển ứng dụng Web được base dựa trên ngôn ngữ lập trình Ruby. Ruby là một ngôn lập trình mã nguồn mở, linh hoạt, với một sự nổi bật về sự đơn giản dễ dùng và hữu ích. Nó có cú pháp rõ ràng, tự nhiên dễ đọc và dễ dàng để viết.
Lịch sử ra đời
Lịch sử hình thành của ngôn ngữ Ruby:
Ruby được tạo ra bởi Yukihiro “Matz” Matsumoto từ 24 tháng 2, 1993 và đưa ra bản chính thức vào năm 1995. Ruby kế thừa và chịu nhiều ảnh hưởng từ ngôn ngữ lập trình Perl.
Nguồn gốc của Rails:
Rails ra mắt công chúng lần đầu tiên vào năm 2004, Rails thoạt đầu được dùng như là nền tảng cho một công cụ quản lý dự án được đặt tên là Basecamp và được tạo ra bởi nhà phát triển web David Heinemeier Hansson, một nhân viên của công ty phát triển web 37signals (Mỹ).
Ruby cung cấp một sự kết hợp giữa những các công cụ tốt nhất, thư viện chất lượng và cách tiếp cận tốt tới phần mềm. Bên cạnh đó cộng đồng Ruby cũng cực kỳ lớn.
Code: chất lượng của các phần mềm viết bởi Ruby code khá chất lượng và ổn định.
Công cụ: Rails cung cấp cho ta những công cụ tuyệt vời giúp chúng ta triển khai được nhiều tính năng hơn nhưng tốn ít thời gian hơn, nó còn cung cấp một cấu trúc chuẩn cho ứng dụng web.
Thư viện: Rails cung cấp cho ta gem, tất cả gem đều có thể sử dụng một cách hoàn toàn miền phí và có thể dễ dàng tra cứu.
Cộng đồng: Cộng đồng Ruby rất lớn. Điều này giúp cải thiện những sản phẩm của Ruby rất nhiều và đây cũng là một lý do mà thư viện của Ruby lại tuyệt vời như vậy. Ruby cũng là một trong số những ngôn ngữ lập trình phổ biến nhất trên Github.
Hiệu suất: Ruby là một ngôn ngữ gọn gàng, khi mà sử dụng kết hợp cùng các thư viện hỗ trợ, Ruby on Rails cho phép bạn phát triển chức năng cho ứng dụng web một cách khá là nhanh chóng.
Tương lai: Nếu so với nhưng ngôn ngữ lập trình đang phát triển mạnh tại Việt Nam như PHP, Java hay .Net thì tỉ lệ “đối thủ” sẽ cao để kiếm được việc làm nếu như bạn chọn những ngôn ngữ lập trình đó. Trong khi đó, với việc làm Ruby on Rails thì tỉ lệ này sẽ thấp. Khi số lượng cung thấp hơn cầu thì giá lương sẽ tăng cao.
Ruby on Rails thường được các công ty startup yêu thích sử dụng cho backend của họ, vd như có công ty Wefit là startup nổi bật về kết nối các phòng tập Gym, hay như startup triệu đô Logivan
Cách đây 2 năm (năm 2017), bên Pinterest đã tập trung build 1 đội viết lại trang web trên mobile sử dụng Progressive Web App.
Sau khi đã tối ưu được tốc độ load trang, thì điều tiếp theo họ nghĩ là làm thế nào để hiển thị dữ liệu được nhanh hơn.