Trong phần trước mình đã khái quát các kiến thức dành cho Backend Engineer như sau:

NoSQL/Cache

  • Memcached
  • Redis
  • DynamoDB
  • Cassandra

Memcached và Redis tôi đều có kinh nghiệm trong thực tế đang làm. Đây là hai kỹ thuật cũ kỹ nhưng nó là 2 đại diện tiêu biểu cho KVS (key value store) và cache từ ngàn đời nay. Ít nhiều trong một số dự án sẽ rất có ích vì một vài ưu điểm nhanh và đơn giản.

Gần đây tôi có chú ý đến DynamoDB của AWS và Apache Cassandra.

DynamoDB là một hệ quản trị CSDL NoSQL của Amazon Web Service có tốc độ nhanh, ổn định phù hợp xử lý dữ liệu lớn. DynamoDB tự động phân tán dữ liệu để đảm bảo truy cập với hiệu suất cao và không bị gián đoạn. Chúng ta có thể hoàn toàn có thể phó thác gánh nặng quản lý và mở rộng dữ liệu mà không cần quan tâm đến việc cung cấp thêm phần cứng, thiết lập cài đặt và sao chép dữ liệu. Người dùng chỉ cần quan tâm đến capacity unit - chính là đọc thông lượng đọc ghi của bảng.

Nói về phần mềm trung gian NoSQL dẫn đầu là Google BigTable và Amazon Dynamo, nhưng nhiều thứ khác cũng xuất hiện trong thế giới open source. Trong số đó, Apache Cassandra (Cassandra) đang thu hút sự chú ý đặc biệt gần đây. Cassandra là một cơ sở dữ liệu phân tán kết hợp mô hình dữ liệu của Google Bigtable với thiết kế hệ thống phân tán như bản sao của Amazon Dynamo. Tất cả được thực hiện bởi Java và được cung cấp trong ASL 2 (Giấy phép Phần mềm Apache Phiên bản 2).

Các tính năng ưu việt của Cassandra bao gồm 9 điểm sau:

  • Thích hợp để sử dụng thực tế
  • Khả năng chịu lỗi cao
  • Kiến trúc không có SPOF (một điểm gây tổn hại)
  • Mức độ tự do kiểm soát nhất quán
  • Mô hình dữ liệu phong phú
  • Có thể tăng cường cải thiện truy suất dữ liệu
  • Tính khả dụng cao
  • Hỗ trợ các ngôn ngữ khác nhau dưới dạng client code
  • Dễ dàng nắm bắt trạng thái bên trong của máy chủ bằng JMX/Dễ giám sát

REST API

Tất nhiên kiến thức về REST API là tất yếu cần thiết cho lập trình web rồi. Một vấn đề mà nhiều bạn mới tìm hiểu về RESTful cũng thường cảm thấy bối rối đó là REST và RESTful khác nhau như thế nào. REST là viết tắt của cụm từ Representational State Transfer và các ứng dụng sử dụng kiểu thiết kế REST thì được gọi là RESTful (-ful là tiếp vị ngữ giống như beauty và beautiful). Tất nhiên bạn cũng có thể sử dụng thuật ngữ REST thay cho RESTful và ngược lại. RESTful API là một tiêu chuẩn dùng trong việc thết kế các thiết kế API cho các ứng dụng web để quản lý các resource. RESTful là một trong những kiểu thiết kế API được sử dụng phổ biến nhất ngày nay.

Tham khảo về các thiết kế RESTful
REST入門 基礎知識 - Qiita

Tham khảo về các tool tài liệu cho API
GoConの前哨戦として各種API仕様記述フォーマットについて概要を述べておく - Qiita
APIドキュメント標準化 現状確認 : エキサイト公式　エンジニアブログ

Authentication

Tôi không nghĩ rằng cần phải hiểu các chi tiết của các phương pháp xác thực khác nhau nhưng có một vài bài viết sau nói về xác thực của OAuth và OpenID Connect có thể tham khảo được

一番分かりやすい OAuth の説明 - Qiita
一番分かりやすい OpenID Connect の説明 - Qiita
JSON Web Token の効用 - Qiita

Chú ý:
OpenID về mặt kỹ thuật là một URL mà người dùng sở hữu (ví dụ alice2016.openid.com), vì thế một vài website cung cấp tùy chọn nhập OpenID một cách thủ công.
Phiên bản mới nhất của OpenID là OpenID Connect, nó kết hợp xác thực của OpenID (OpenID authentication) và ủy quyền/ phân quyền của OAuth2 (OAuth2 authorization).
Facebook trước đây sử dụng OpenID nhưng hiện nay đã chuyển sang Facebook Connect.

Messaging

  • Amazon SQS
  • Amazon SNS
  • Cloud Pub/Sub

Trên đây là các dịch vụ Messaging. Về phần này mình cũng không nắm được nhiều lắm. Nhưng có SQS là tiêu biểu cho các dịch vụ Message nói chung.

Full text search

Nói đơn giản dễ hiểu, full text search (gọi tắt là FTS) là cách tự nhiên nhất để tìm kiếm thông tin, hệt như Google, ta chỉ cần gõ từ khóa và nhấn enter thế là có kết quả trả về. Phạm vi bài viết này chỉ đề cập, giới thiệu sơ lược về FTS trong MySQL mà không bàn về các FTS engine như Sphinx hay Solr. Trong đó nổi tiếng nhất là ElasticSearch

Docker

Nếu bạn đang làm ở một công ty công nghệ thông tin, chắc rằng bạn đã được nghe nói về Docker. Thậm chí trong số các công nghệ "hot" nhất hiện nay như PostgreSQL, MongoDB, Apache Spark, Bash shell, AWS, Kafka, Jenkins, thì Docker vẫn nổi bật nhất. Các doanh nghiệp đều muốn Docker. Docker ngày càng trở nên gần gũi với các start-ups cũng như với những tập đoàn kinh tế lớn cho dù nó chỉ đang là một công cụ rất mới.

Trong phạm vi nhỏ tự mình tìm hiểu thì ít nhất phải làm đủ các bước sau:

  1. Viết Dockerfile
  2. Chạy docker build để build Docker Image
  3. Sau đó sẽ đưa Image này lên DockerHub nào đó bằng docker push
  4. Để lấy Image về dùng docker pull
  5. Để chạy Docker Image dùng docker run
  6. Thiết lập port để có thể access vào Container

Hiện tại cộng đông docker khá đông và hung hãn, nên có thể tìm được tài liệu cũng như các bài viết hướng dẫn ở bất cứ đâu.

Web Server

Hiện nay có 2 Web Server phổ biến nhất là Apache và nginx.
Apache là một thành phần web server của các LAMP phổ biến (Linux, Apache, MySQL, PHP). Mặc dù ngày nay có rất nhiều thành phần web stack khác (ví dụ, NodeJS, rich clients JS frameworks, dịch vụ đám mây khác nhau, vv), LAMP vẫn còn rất phổ biến.
nginx đã được tạo ra để đáp ứng với những thách thức C10K xử lý ít nhất 10.000 khách hàng kết nối đồng thời trên một máy chủ duy nhất. NGINX sử dụng một kiến trúc event-driven không đồng bộ để xử lý những số lượng kết nối khổng lồ này. Kiến trúc này làm cho việc xử lý cao và dao động tải nhiều hơn dự đoán về cách sử dụng bộ nhớ RAM, sử dụng CPU, và độ trễ.
Với nhiều ưu điểm nhanh, dễ tương thích, nginx ngày cà phổ biến, nên không càn phải tìm hiểu apache cũng được.

Web Socket

WebSockets cung cấp khả năng giao tiếp hai chiều mạnh mẽ, có độ trễ thấp và dễ xử lý lỗi. Không cần phải có nhiều kết nối như phương pháp Comet long-polling và cũng không có những nhược điểm như Comet streaming.
Nhờ vậy mà được ứng dụng trong nhiều ứng dụng như Game, Chat, hoặc là các service như là Trello. Trong tương lai sẽ còn nhiều những ứng dụng real time hơn nữa nên Socket sẽ trở thành kỹ thuật không thể thiếu.
Có nhiều ngôn ngữ và Framework khác nhau để viết socket nhưng tôi ấn tượng với Elixir + Phoenix với cách viết ngắn nhưng vẫn đảm bảo chịu tải tốt.

GraphQL

GraphQL là một tiêu chuẩn API mới cung cấp một giải pháp thay thế hiệu quả, mạnh mẽ và linh hoạt hơn REST. Ban đầu GraphQL được Facebook phát triển và hiện là một open-source đang được một một cộng đồng lớn bao gồm các công ty và các cá nhân trên khắp thế giới chung tay xây dựng.

Như ta đã biết hiện tại API đã trở thành các thành phần phổ biến của cơ sở hạ tầng phần mềm. Một API định nghĩa cách client có thể tải dữ liệu từ server và GraphQL cho phép client có thể định nghĩa chính xác dữ liệu nào nó cần từ một API. Thay vì cần nhiều endpoint mà mỗi endpoint trả về một cấu trúc dữ liệu cố định, GraphQL server chỉ cần một endpoint duy nhất và phản hồi chính xác dữ liệu mà client yêu cầu.

Với đầu đủ thông tin cho người mới bắt đầu mọi người có thể tham khảo một blog khác ở đây:

RESTful thực sự rất tuyệt vời! Tôi có thể khẳng định như vậy. Nhưng khi sự phát triển của mobile apps và web one-page-application ngày càng trở nên mạnh mẽ, RESTful bộc lộ những điểm yếu của nó:

  • Việc chia nhỏ theo resource khiến ta phải khởi tạo nhiều request cùng lúc để có thể lấy hết lượng data mong muốn hiển thị.
  • Khi dữ liệu có nhiều lớp, việc truy vấn trong database trở nên khó khăn, việc xuất dữ liệu ra trở nên kém hiệu quả bởi khả năng lặp lại dữ liệu cao.
  • Logic backend trở nên phức tạp và phình to nhanh chóng khi một API phục vụ cho nhiều application khác nhau.
  • Việc phát triển riêng biệt các component trong hệ thống vẫn còn khó khăn, bởi bất cứ thay đổi nào của một component, đều dẫn tới có thể ảnh hưởng tới các component còn lại. Ví dụ của tôi về mối quan hệ giữa backend dev và frontend dev là một minh chứng đơn giản.

Trong khi đó, với GraphQL

  • Tất cả data mong muốn có thể gộp chung vào một truy vấn, tới một endpoint duy nhất
    Với phương pháp duyệt cây, mỗi data node chỉ cần duyệt qua một lần duy nhất là đã có thể dùng cho mọi nơi trong data set, không phụ thuộc vào độ phức tạp của format dữ liệu.
  • Việc thay đổi phạm vi truy cập tới một trường nào đó cũng trở nên đơn giản, khả năng ảnh hưởng tới các phần khác thấp
  • Việc phát triển riêng biệt các component trở nên hiện thực hơn bao giờ hết.

Tổng kết

Nói chung tình hình công nghệ, kỹ thuật ngày cành biến động nhanh. Các startup mọc lên như nấm. Khi việc phát triển ứng dụng có thể giao cho các kỹ sư mới ra trường hoặc thực tập nhưng cần thiết phải có chuyên gia về hệ thống. Trên đây là những kỹ thuật cần thiết đê cập nhật lại kiến thức.
Mình xin tổng hợp lại lộ trình 1 lần nữa bằng 1 bức tranh rõ ràng hơn. Chúc mọi người sẽ thành công trên con đường trở thành một chuyên gia hệ thống.

uc?id=1_lmiOqtKKoJyaq5zMyXuqy-hf27c6MEr&export=download