Thật ra thì với các bạn sinh viên mới ra trường đi làm (con đang là Internship hay Fresher) thì câu hỏi này là top những câu hỏi gặp phải khi phỏng vấn đó nha.

Bên cạnh đó, hiểu rõ sự khác nhau giữa Interface và Abstract Class sẽ giúp chúng ta có thể thiết kế được các ứng dụng mà nó có các kết nối lỏng lẽo (loosely coupled) và dễ dàng mở rộng. Vấn đề này bạn sẽ hiểu rõ hơn trong bài viết nói về Dependency Injection Principle. Một điều quan trọng là bạn không thể chọn dùng Interface hay Abstract Class nếu chỉ biết chúng khác nhau thế nào.

<h2>Interface trong C#</h2>

Có thể hiểu đơn giản Interface là một bản thiết kế cho bất kì class muốn thực hiện nó. Nghĩa là nó chỉ có phần khai báo các phương thức/sự kiện và thuộc tính. Các class muốn thực hiện Interface này sẽ viết code implement cho tất cả các khai báo của Interface này.

<h3>Các tính chất của Interface</h3>

<ul>
	<li>Interface không cung cấp việc kế thừa như Class hay Abstract Class mà nó chỉ khai báo phương thức/sự kiện để các lớp khác thực hiện nó.</li>
	<li>Nó không được khởi tạo nhưng nó có thể được tham chiếu bởi đối tượng của lớp thực hiện nó. ví dụ:</li>
</ul>

<pre>
<code>IUserRepository user = new UserRepository();</code></pre>

<ul>
	<li>Không có interface lồng nhau (nested interface)</li>
	<li>Không có constructor, destructor, constants, static và variable.</li>
	<li>Một interface có thể kế thừa từ một hoặc nhiều interface khác.</li>
</ul>

<pre>
<code>public interface IList : ICollection, IEnumerable, IEnumerable</code></pre>

<ul>
	<li>Một interface có thể mở rộng một interface khác.</li>
	<li>Một class có thể implement một hoặc nhiều interfaces.</li>
	<li>Mọi phương thức, property đều mặc định là public.</li>
</ul>

<h2>Abstract Class trong C#</h2>

Lớp trừu tượng (Abstract Class) là một loại lớp đặc biệt không thể khởi tạo được và nó hoạt động như một lớp cơ sở cho các lớp khác.

 

Mục đích của Abstract Class là cung cấp các chức năng cơ bản mặc định hoặc các chức năng chung chung mà các lớp dẫn suất có thể thực hiện và ghi đè. Nghĩa là, bạn có thể viết định nghĩa cho phương thức trong Abstract Class, các phương thức trong Abstract Class có thể vừa trừu tượng vừa cụ thể.

<h2>Các tính chất của Abstract Class</h2>

<ul>
	<li>Một Abstract Class không thể được khởi tạo.</li>
	<li>Abstract Class có thể chứa các phương thức trừu tượng và cụ thể (abstract method – virtual method).</li>
	<li>Một Abstract Class không thể là một Sealed Class. Vì Sealed Class không cho phép kế thừa.</li>
	<li>Không thể kế thừa từ một Class hay Interface.</li>
	<li>Lớp dẫn xuất từ Abstract Class phải implement tất cả các abstract methods của Abstract Class đó.</li>
	<li>Trong Abstract Class thì các abstract method chỉ có khai báo. Còn virtual method thì có thể được định nghĩa.</li>
	<li>Abstract Class có thể dùng các access modifiers như: private, protected, internal. Nhưng các abstract/virtual methods thì không thể dùng private.</li>
	<li>Abstract Class có thể có contructor, destructor, constants, fields</li>
	<li>Không hỗ trợ đa kế thừa.</li>
</ul>

<pre>
<code>using System;

namespace ConsoleApp1
{
 class Program
 {
 static void Main(string[] args)
 {
 SampleClass sc = new SampleClass();
 //AbsSimpleClass absSimpleClass = new AbsSimpleClass(); // Error here
 
 sc.Paint();
 Console.ReadKey();

 //Output:
 //--> AbsSimpleClass constructor here
 //--> Paint method here
 }

 public abstract class AbsSimpleClass
 {
 public AbsSimpleClass()
 {
 Console.WriteLine("AbsSimpleClass constructor here");
 }

 public abstract void DoSomething();

 public virtual void Paint()
 {
 Console.WriteLine("Paint method here");
 }
 }

 public class SampleClass : AbsSimpleClass
 {
 public override void DoSomething()
 {
 Console.WriteLine("Do something here");
 } 
 }
 } 
}</code></pre>

<h3>Những điểm khác nhau giữa Interface và Abstract Class</h3>

<table>
	<thead>
		<tr>
			<td> </td>
			<td>Interface</td>
			<td>Abstract Class</td>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>Constructors, Fields and Constants</td>
			<td>Không</td>
			<td>Có</td>
		</tr>
		<tr>
			<td>Multiple inheritance</td>
			<td>Một class có thể hiện thực nhiều interface.(tạm coi là thừa kế)</td>
			<td>Không hỗ trợ đa thừa kế</td>
		</tr>
		<tr>
			<td>Default implementation</td>
			<td>Không thể định nghĩa code xử lý, chỉ có thể khai báo.</td>
			<td>Có thể định nghĩa thân phương thức, property.</td>
		</tr>
		<tr>
			<td>Access Modifiers</td>
			<td>Mọi phương thức, property đều mặc định là public.</td>
			<td>Có thể xác định modifier.</td>
		</tr>
		<tr>
			<td>Adding functionality</td>
			<td>Mọi phương thức, property của interface cần được hiện thực trong class.</td>
			<td>Không cần thiết.</td>
		</tr>
	</tbody>
</table>

<h2>Khi nào nên dùng Interface</h2>

<ul>
	<li>Cần cung cấp các chức năng chung cho các lớp không liên quan.</li>
	<li>Cần nhóm các đối tượng dựa trên các hành vi phổ biến.</li>
	<li>Cần sử dụng đa hình vì một lớp có thể thực hiện nhiều interfaces.</li>
	<li>Cần tạo các thành phần (components) được ghép lỏng lẻo, dễ bảo trì và dùng như 1 plugin vì việc implement cho interface được tách biệt với nó.</li>
</ul>

<h2>Khi nào nên dùng Abstract Class</h2>

<ul>
	<li>Cần sử dụng kế thừa.</li>
	<li>Cần cung cấp các phương thức mặc định cũng như các phương thức phổ biến mà nhiều lớp dẫn xuất có thể thực thi và ghi đè.</li>
	<li>Cần tạo nhiều phiên bản cho các thành phần (components). Bạn có thể thêm các thuộc tính và phương thức vào Abstract Class mà không vi phạm mã và tất cả các lớp kế thừa được tự động cập nhật với thay đổi.</li>
</ul>

Một vấn đề khác là các Interfaces có thể được implement ngầm hoặc rõ ràng (implemented implicitly or explicitly).

À, còn một vấn đề nữa. Như các bạn thấy một Class có thể implement một hoặc nhiều interfaces. Vậy nếu một class implement 2 interfaces mà trong đó có cùng 1 phương thức (method) thì sẽ thế nào?

Thử mở Visual Studio và chạy console app sau xem như thế nào nhé:

<pre>
<code>using System;

namespace ConsoleApp1
{
 class Program
 {
 static void Main(string[] args)
 {
 SampleClass sc = new SampleClass();
 IControl ctrl = new SampleClass();
 ISurface srfc = new SampleClass();

 sc.Paint();
 ctrl.Paint();
 srfc.Paint();
 }

 interface IControl
 {
 void Paint();
 }
 interface ISurface
 {
 void Paint();
 }
 class SampleClass : IControl, ISurface
 {
 public void Paint()
 {
 Console.WriteLine("Paint method in SampleClass");
 Console.ReadKey();
 }
 void IControl.Paint()
 {
 Console.WriteLine("Paint method in IControl");
 Console.ReadKey();
 }

 void ISurface.Paint()
 {
 Console.WriteLine("Paint method in ISurface");
 Console.ReadKey();
 }
 }
 }
}</code></pre>

Hy vọng bài viết này sẽ giúp bạn hiểu rõ hơn về Interface và Abstract Class. Từ đó giúp bạn xây dựng ứng dụng tốt hơn.

Mình cũng rất mong được các bạn góp ý để bổ sung và hoàn chỉnh kiến thức này.

Nói về chủ đề này thì đã có quá nhiều bài viết trên mạng, thế nhưng mục đích mình bài này là để cho những đứa em của mình cũng đang theo con đường lập trình có một nơi để tham khảo. Rất hy vọng được các bạn góp ý để kiến thức mình chia sẽ được tốt hơn.

Interface và Abstract class, tại sao thế này và tại sao thế kia?

<html><body><pre><code class="language-php">&lt;?php
namespace App\Http\Controllers\Web\Admin;
use App\Http\Requests\CreateActivityRequest;
use App\Http\Requests\UpdateActivityRequest;
use App\Models\Activity;
use App\Repositories\Eloquent\ActivityRepository;
use App\Services\ActivityService;
class ActivityController extends BaseAdminController
{
 /**
 * @var ActivityService
 */
 private ActivityService $activityService;
 public function __construct(ActivityService $activityService)
 {
 $this-&gt;activityService = $activityService;
 }
 public function index()
 {
 $activities = $this-&gt;activityService-&gt;getActivity();
 return view('admin.activities.index', [
 'activities' =&gt; $activities
 ]);
 }
 public function create()
 {
 $latestOrder = app(ActivityRepository::class)-&gt;getLatestOrder();
 return view('admin.activities.create', [
 'latestOrder' =&gt; $latestOrder
 ]);
 }
 public function store(CreateActivityRequest $request)
 {
 $data = $request-&gt;validated();
 $response = $this-&gt;activityService-&gt;store($data);
 if ($response['status']) {
 return $this-&gt;responseSuccess($response['message'], [
 'redirect_url' =&gt; route('admin.activity.index')
 ]);
 }
 return $this-&gt;responseError($response['message']);
 }
 
 
 
 public function edit(Activity $activity)
 {
 return view('admin.activities.edit', [
 'activity' =&gt; $activity,
 ]);
 }
 public function update(Activity $activity, UpdateActivityRequest $request)
 {
 $data = $request-&gt;validated();
 $response = $this-&gt;activityService-&gt;update($activity, $data);
 if ($response['status']) {
 return $this-&gt;responseSuccess($response['message'], [
 'redirect_url' =&gt; route('admin.activity.index')
 ]);
 }
 return $this-&gt;responseError($response['message']);
 }
 public function destroy(Activity $activity)
 {
 $response = $this-&gt;activityService-&gt;delete($activity);
 if (!!$response['status']) {
 return $this-&gt;responseSuccess($response['message']);
 }
 return $this-&gt;responseError($response['message']);
 }
}
</code></pre>another one<pre><code class="language-cs">class Animal // Base class (parent) 
{
 public void animalSound() 
 {
 Console.WriteLine("The animal makes a sound");
 }
}

class Pig : Animal // Derived class (child) 
{
 public void animalSound() 
 {
 Console.WriteLine("The pig says: wee wee");
 }
}

class Dog : Animal // Derived class (child) 
{
 public void animalSound() 
 {
 Console.WriteLine("The dog says: bow wow");
 }
}

class Program 
{
 static void Main(string[] args) 
 {
 Animal myAnimal = new Animal(); // Create a Animal object
 Animal myPig = new Pig(); // Create a Pig object
 Animal myDog = new Dog(); // Create a Dog object

 myAnimal.animalSound();
 myPig.animalSound();
 myDog.animalSound();
 }
}</code></pre> </body></html>

blog quang test

Dung Leanh

Khoa Nguyen

Vien Truong

Apply 3d content on a webpage using three.js library

Đức Viễn

<html><body> <h2>Fundamentals</h2>Let’s understand the structure of a three.js app.<img src="https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-KiLNsi89QWKF9DF9N6DLRFPNODoezvOwDukn6rbn.png">Things to notice about the diagram above.<ul><li>Renderer is the place where we are going to put the result of our scene. In Three.js we can have multiple scenes and each one can have different objects.</li><li>Mesh is made up of a Geometry and a Material.</li><li>Geometry — which defines its shape.</li></ul>Material — which defines its appearance.<figure class="image"><img src="https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-pa8Cu08FzGcjD7YcWAeAH9lEI97QPQnu0aTtAT8G.png"></figure></body></html>

Many individuals wish to build their own 3D website but may feel unsure of where to begin and have the confidence it would run smoothly. If you’re searching for a way to build 3d websites as a developer then this article will 100% help you.

<html><body><pre><code class="language-c">Quản Trị Phân Tán</code></pre>Kiến trúc microservices ủng hộ quản trị phân tán.Nhìn chung, quản trị nghĩa là thiết lập và thực thi phương thức mà con người và các giải pháp làm việc cùng nhau để đạt được mục tiêu. Trong ngữ cảnh SOA, quản trị SOA (SOA governance) hướng dẫn việc phát triển các services có thể tái sử dụng, thiết lập cách services được thiết kế, phát triển và cách chúng thay đổi theo thời gian. Nó thiết lập một giao kèo giữa người cung cấp services và người sử dụng services, thông báo cho người sử dụng những thứ họ có thể nhận được và người sử dụng những thứ họ phải cung cấp. Trong quản trị SOA, có hai kiểu quản trị phổ biến:<ul><li>Quản trị khi thiết kế – định nghĩa và kiểm soát việc tạo services, thiết kế và thực thi các chính sách của services.</li><li>Quản trị khi triển khai/ chạy – khả năng đảm bảo các chính sách của services trong quá trình hoạt động.</li></ul>Vậy trong microservices thì quản trị là gì?Microservices được xây dựng động lập và phân tán với nền tảng công nghệ khác nhau. Do đó, việc thiết lập một tiêu chuẩn thiết kế và phát triển chung là không cần thiết. Chúng ta có thể kết luận về khả năng quản trị phân tán trong kiến trúc microservices như sau:<ul><li>Không cần phải có một hệ quản trị tập trung khi thiết kế.</li><li>Microservices có thể tự quyết định thiết kế và phát triển của nó.</li><li>Kiến trúc ủng hộ và hỗ trợ việc chia sẻ các services chung hay có thể tái sử dụng.</li><li>Một số mặt của quản trị trong quá trình hoạt động như SLAs, điều phối, giám sát, bảo mật hay tìm kiếm dịch vụ (service discovery) có thể được phát triển ở cấp API Gateway.</li></ul><h3>Service Registry &amp; Service Discorvery (Truy Tìm Dịch Vụ).</h3>Trong microservices, số lượng services mà bạn cần xử lý khá lớn. Và địa điểm của chúng có thể thay đổi nhanh và thường xuyên vì tính chất của việc phát triển microservices là nhanh. Nên bạn cần phải xác định được vị trí của một service trong quá trình chạy. Giải pháp cho vấn đề này là Service Registry.<h3>Service Registry</h3>Service Registry giữ các thực thể microservices và địa chỉ của chúng. Thực thể microservices được đăng kí với service registery khi bắt đầu chạy và hủy đăng kí khi tắt. Người dùng có thể tìm các services đang tồn tại và địa chỉ của chúng qua service registry.<h3>Service Discovery</h3>Để tìm các microservices đang tồn tại và địa điểm của chúng, chúng ta cần một quy trình truy tìm dịch vụ. Có hai mô hình là Client-side Discovery và Server-side Discovery. Hãy cùng xem xét hai mô hình này.Client-side Discovery – Với mô hình này, client hay API Gateway lấy thông tin địa điểm của một thực thể service bằng cách truy vấn Service Registry.<img src="https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-dU8E9DeAowxJUvH7iVz4fjcjUHZE4xeUtfavIeEh.png" alt="">Client hay API Gateway phải thực hiện logic tìm kiếm service bằng cách gọi vào Service Registry.Server-side Discovery – Với cách này, client hay API Gateway gửi yêu cầu lên một component (có thể là một Load Balancer). Component này sẽ gọi Service Registry và quyết định địa điểm của các microservices.<img src="https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-IhnnuxS99BATpwpcuEKQmgRNUrpZyFBmb3uaZu9d.png" alt="">Một số giải pháp triển khai microservices như Kubernetes cung cấp mô hình server-side discovery.</body></html>

Quản Trị Phân Tán, Service Registry & Service Discorvery (Truy Tìm Dịch Vụ), Service Registry, Service Discovery

<h2>Kiến tr&uacute;c nguy&ecirc;n khối (Monolithic Architecture)</h2>

Ứng dụng phần mềm doanh nghiệp được thiết kế để đ&aacute;p ứng nhiều y&ecirc;u cầu kinh doanh của doanh nghiệp. Do đ&oacute;, c&aacute;c phần mềm cung cấp h&agrave;ng trăm c&aacute;c t&iacute;nh năng v&agrave; tất cả những t&iacute;nh năng n&agrave;y đều được g&oacute;i trong một ứng dụng monolithic. V&iacute; dụ: ERPs, CRMs hay nhiều phần mềm kh&aacute;c chứa h&agrave;ng trăm t&iacute;nh năng. Việc triển khai, sửa lỗi, mở rộng v&agrave; n&acirc;ng cấp những phần mềm khổng lồ n&agrave;y trở th&agrave;nh một cơn &aacute;c mộng.

Kiến tr&uacute;c hướng dịch vụ (Service Oriented Architecture &ndash;&nbsp;SOA) được thiết kể để giải quyết một phần của vấn đề bằng c&aacute;ch giới thiệu kh&aacute;i niệm &ldquo;service&rdquo;. Một dịch vụ (service) l&agrave; một nh&oacute;m tổng hợp c&aacute;c t&iacute;nh năng tương tự trong một ứng dụng. Do đ&oacute; trong&nbsp;SOA, ứng dụng phần mềm được thiết kế như một tổ hợp của c&aacute;c dịch vụ. Tuy nhi&ecirc;n, với SOA, giới hạn hay phạm vi của một dịch vụ kh&aacute; l&agrave; rộng v&agrave; được định nghĩa kh&aacute; &ldquo;th&ocirc;&rdquo; (coarse-grained). Việc n&agrave;y khiến c&aacute;c services cũng c&oacute; thể trở n&ecirc;n qu&aacute; to v&agrave; phức tạp.

&nbsp;

<img alt="" height="282" src="/ckfinder/userfiles/images/image-20220905135954-3.png" width="241" />

Trong phần lớn trường hợp, dịch vụ trong SOA l&agrave; độc lập nhưng ch&uacute;ng lại được triển khai chung. Tương tự như ứng dụng monolithic, những dịch vụ n&agrave;y to v&agrave; phức tạp l&ecirc;n theo thời gian v&igrave; thường xuy&ecirc;n th&ecirc;m c&aacute;c t&iacute;nh năng. V&agrave; thế l&agrave; những ứng dụng n&agrave;y lại trở th&agrave;nh một mớ c&aacute;c dịch vụ monolithic, cũng kh&ocirc;ng c&ograve;n kh&aacute;c mấy so với kiến tr&uacute;c nguy&ecirc;n khối th&ocirc;ng thường.

H&igrave;nh 1&nbsp;thể hiện một ứng dụng gồm nhiều services. Những services n&agrave;y được triển khai c&ugrave;ng một l&uacute;c v&agrave;o 1 ứng dụng lớn. D&ugrave; b&ecirc;n trong c&oacute; gồm c&aacute;c services th&igrave; đ&acirc;y l&agrave; một ứng dụng monolithic. Một số t&iacute;nh chất của kiến tr&uacute;c nguy&ecirc;n khối (Monolithic Architecture):

<ul>
	<li>Được thiết kế, ph&aacute;t triển v&agrave; triển khai theo một khối duy nhất.</li>
	<li>Ứng dụng monolithic phức tạp v&agrave; to g&acirc;y kh&oacute; khăn cho việc bảo tr&igrave;, n&acirc;ng cấp v&agrave; th&ecirc;m t&iacute;nh năng mới.</li>
	<li>Kh&oacute; &aacute;p dụng ph&aacute;t triển kiểu Agile.</li>
	<li>Phải triển khai lại to&agrave;n bộ hệ thống d&ugrave; chỉ cập nhật hay n&acirc;ng cấp một phần.</li>
	<li>Mở rộng: phải mở rộng cả khối ứng dụng, gặp kh&oacute; khăn nếu c&oacute; c&aacute;c y&ecirc;u cầu về t&agrave;i nguy&ecirc;n kh&aacute;c nhau (v&iacute; dụ một service y&ecirc;u cầu th&ecirc;m CPU, service kh&aacute;c lại y&ecirc;u cầu nhiều memory).</li>
	<li>Độ tin cậy: một service kh&ocirc;ng ổn định c&oacute; thể sập cả hệ thống.</li>
	<li>Kh&oacute; đổi mới: ứng dụng monolithic phải sử dụng chung c&ocirc;ng nghệ n&ecirc;n kh&oacute; thay đổi hay &aacute;p dụng c&ocirc;ng nghệ mới.</li>
</ul>

Những t&iacute;nh chất giới hạn tr&ecirc;n của kiến tr&uacute;c nguy&ecirc;n khối dẫn tới sự ph&aacute;t triển của kiến tr&uacute;c dịch vụ nhỏ (Microservices Architecture).

<h2>Kiến tr&uacute;c dịch vụ nhỏ (Microservices Architecture)</h2>

Mục ti&ecirc;u nền tảng của kiến tr&uacute;c microservices l&agrave; x&acirc;y dựng một ứng dụng m&agrave; ứng dụng n&agrave;y l&agrave; tổng hợp của nhiều services nhỏ v&agrave;&nbsp;độc lập c&oacute; thể chạy ri&ecirc;ng biệt, ph&aacute;t triển v&agrave; triển khai độc lập.

Một số kh&aacute;i niệm về microservices n&oacute;i về qu&aacute; tr&igrave;nh chia t&aacute;ch ứng dụng monolithic th&agrave;nh nh&oacute;m c&aacute;c services độc lập. Tuy nhi&ecirc;n, theo quan điểm của t&ocirc;i, microservices kh&ocirc;ng chỉ về chia t&aacute;ch c&aacute;c servcies sẵn c&oacute; trong monolithic.

&Yacute; tưởng quan trọng ch&iacute;nh l&agrave; nh&igrave;n v&agrave;o c&aacute;c t&iacute;nh năng trong một ứng dụng monolithic, ta c&oacute; thể nhận biết, x&aacute;c định c&aacute;c y&ecirc;u cầu v&agrave; khả năng cần thiết để đ&aacute;p ứng một nghiệp vụ. Sau đ&oacute; từng năng lực nghiệp vụ n&agrave;y sẽ được x&acirc;y dựng th&agrave;nh những service nhỏ, độc lập.&nbsp;Những services n&agrave;y c&oacute; thể sử dụng c&aacute;c nền tảng c&ocirc;ng nghệ kh&aacute;c nhau v&agrave; phục vụ một mục đ&iacute;ch cụ thể v&agrave; c&oacute; giới hạn.

Theo đ&oacute;, v&iacute; dụ về hệ thống trong&nbsp;h&igrave;nh 1&nbsp;c&oacute; thể được chia theo microservices như trong&nbsp;h&igrave;nh 2. Đ&acirc;y c&oacute; thể l&agrave; một ứng dụng phần mềm b&aacute;n h&agrave;ng, với kiến tr&uacute;c microservices, mỗi chức năng kinh doanh hay trong doanh nghiệp được t&aacute;ch th&agrave;nh một microservices. Trong kiến tr&uacute;c microservices, một service mới được tạo ra từ những services gốc trong kiến tr&uacute;c monolithic.

&nbsp;

<img alt="" height="322" src="/ckfinder/userfiles/images/image-20220905140008-4.png" width="302" />

Tiếp theo, ch&uacute;ng ta sẽ n&oacute;i về c&aacute;c nguy&ecirc;n tắc ch&iacute;nh của kiến tr&uacute;c microservices v&agrave; quan trọng hơn ch&iacute;nh l&agrave; c&aacute;ch ch&uacute;ng được sử dụng trong thực tế.

<h2>Thiết kế Microservices: k&iacute;ch cỡ, phạm vi v&agrave; t&iacute;nh năng</h2>

Bạn c&oacute; thể x&acirc;y dựng ứng dụng mới với microservices hoặc chuyển đổi ứng dụng sẵn c&oacute; sang microservices. Với c&aacute;ch n&agrave;o th&igrave; việc quyết định k&iacute;ch cỡ, phạm vi v&agrave; t&iacute;nh năng của microservices rất quan trọng. C&oacute; thể đ&acirc;y ch&iacute;nh l&agrave; phần kh&oacute; nhất bạn gặp phải khi ph&aacute;t triển hệ thống microservices trong thực tế.

Dưới đ&acirc;y ch&uacute;ng ta sẽ xem x&eacute;t một số vấn đề thực tế v&agrave; những hiểu sai về k&iacute;ch cỡ, phạm vi v&agrave; chức năng của microservices.

<ul>
	<li>Số d&ograve;ng code/ k&iacute;ch cỡ của một đội lập tr&igrave;nh l&agrave; chỉ số kh&ocirc;ng ch&iacute;nh x&aacute;c: c&oacute; v&agrave;i cuộc b&agrave;n luận về k&iacute;ch thước của một service dựa v&agrave;o số lượng d&ograve;ng code hay k&iacute;ch thước của đội ph&aacute;t triển service đ&oacute; (v&iacute; dụ&nbsp;<a href="http://blog.idonethis.com/two-pizza-team/">two-pizza team</a>). Tuy nhi&ecirc;n, những c&aacute;ch đo đếm n&agrave;y kh&ocirc;ng thực tiễn v&agrave; kh&ocirc;ng ch&iacute;nh x&aacute;c, v&igrave; ta c&oacute; thể ph&aacute;t triển services với &iacute;t d&ograve;ng code hoặc với một đội nhỏ nhưng ho&agrave;n to&agrave;n đảm bảo được c&aacute;c nguy&ecirc;n l&yacute; trong kiến tr&uacute;c microservices.</li>
	<li>&ldquo;Micro&rdquo; l&agrave; một từ kh&oacute;a dễ g&acirc;y nhầm lẫn. Một số lập tr&igrave;nh vi&ecirc;n nghĩ rằng họ n&ecirc;n tạo ra services nhỏ hết mức. Điều n&agrave;y l&agrave; một c&aacute;ch hiểu sai.</li>
	<li>Trong SOA, services thường trở th&agrave;nh c&aacute;c cục monolithic với nhiều h&agrave;m, chức năng kh&aacute;c hỗ trợ. V&igrave; vậy, chỉ ph&aacute;t triển services kiểu SOA rồi d&aacute;n nh&atilde;n microservices ho&agrave;n to&agrave;n lạc hướng v&agrave; kh&ocirc;ng mang lại bất k&igrave; lợi &iacute;ch n&agrave;o của kiến tr&uacute;c microservices.</li>
</ul>

Do đ&oacute;, c&acirc;u hỏi l&agrave; ch&uacute;ng ta n&ecirc;n thiết kế services trong kiến tr&uacute;c microservices như thế n&agrave;o th&igrave; ph&ugrave; hợp v&agrave; đ&uacute;ng mực?

Hiện nay, “Microservices” là một trong những thuật ngữ hay từ khóa phổ biến nhất (buzz-words) trong lĩnh vực kiến trúc phần mềm. Bạn có thể tìm thấy khá nhiều tài liệu giới thiệu và nói về những nguyên tắt cũng như lợi ích của microservices, tuy nhiên khá ít tài liệu hướng dẫn cách áp dụng microservices trong những hoàn cảnh thực tế. Bài này chúng ta sẽ tìm hiểu về các khái niệm chính về kiến trúc microservices (MSA) và cách mà bạn sử dụng những nguyên lý này trong thực tiễn.

Microservices: Cưỡi ngựa xem hoa - Phần 1

<h2>Thiết kế Microservices: k&iacute;ch cỡ, phạm vi v&agrave; t&iacute;nh năng</h2>

&nbsp;

Dưới đ&acirc;y ch&uacute;ng ta sẽ xem x&eacute;t một số vấn đề thực tế v&agrave; những hiểu sai về k&iacute;ch cỡ, phạm vi v&agrave; chức năng của microservices.

<ul>
	<li>Số d&ograve;ng code/ k&iacute;ch cỡ của một đội lập tr&igrave;nh l&agrave; chỉ số kh&ocirc;ng ch&iacute;nh x&aacute;c: c&oacute; v&agrave;i cuộc b&agrave;n luận về k&iacute;ch thước của một service dựa v&agrave;o số lượng d&ograve;ng code hay k&iacute;ch thước của đội ph&aacute;t triển service đ&oacute; (v&iacute; dụ&nbsp;<a href="http://blog.idonethis.com/two-pizza-team/">two-pizza team</a>). Tuy nhi&ecirc;n, những c&aacute;ch đo đếm n&agrave;y kh&ocirc;ng thực tiễn v&agrave; kh&ocirc;ng ch&iacute;nh x&aacute;c, v&igrave; ta c&oacute; thể ph&aacute;t triển services với &iacute;t d&ograve;ng code hoặc với một đội nhỏ nhưng ho&agrave;n to&agrave;n đảm bảo được c&aacute;c nguy&ecirc;n l&yacute; trong kiến tr&uacute;c microservices.</li>
	<li>&ldquo;Micro&rdquo; l&agrave; một từ kh&oacute;a dễ g&acirc;y nhầm lẫn. Một số lập tr&igrave;nh vi&ecirc;n nghĩ rằng họ n&ecirc;n tạo ra services nhỏ hết mức. Điều n&agrave;y l&agrave; một c&aacute;ch hiểu sai.</li>
	<li>Trong SOA, services thường trở th&agrave;nh c&aacute;c cục monolithic với nhiều h&agrave;m, chức năng kh&aacute;c hỗ trợ. V&igrave; vậy, chỉ ph&aacute;t triển services kiểu SOA rồi d&aacute;n nh&atilde;n microservices ho&agrave;n to&agrave;n lạc hướng v&agrave; kh&ocirc;ng mang lại bất k&igrave; lợi &iacute;ch n&agrave;o của kiến tr&uacute;c microservices.</li>
</ul>

Do đ&oacute;, c&acirc;u hỏi l&agrave; ch&uacute;ng ta n&ecirc;n thiết kế services trong kiến tr&uacute;c microservices như thế n&agrave;o th&igrave; ph&ugrave; hợp v&agrave; đ&uacute;ng mực?

<h2>Một Số Chỉ Dẫn Khi Thiết Kế Microservices</h2>

<ul>
	<li>Single Responsibility Principle (SRP): một service với phạm vi v&agrave; chức năng giới hạn, tập trung v&agrave;o một nhiệm vụ gi&uacute;p qu&aacute; tr&igrave;nh ph&aacute;t triển v&agrave; triển khai dịch vụ trở n&ecirc;n nhanh ch&oacute;ng hơn.</li>
	<li>Trong qu&aacute; tr&igrave;nh thiết kế, ta n&ecirc;n x&aacute;c định v&agrave; giới hạn c&aacute;c services theo chức năng nghiệp vụ thực tế (theo&nbsp;<a href="http://martinfowler.com/bliki/BoundedContext.html">Domain-Driven-Design</a>).</li>
	<li>Đảm bảo microservices c&oacute; thể ph&aacute;t triển v&agrave; triển khai độc lập.</li>
	<li>Mục ti&ecirc;u của thiết kế l&agrave; phạm vi của microservices phục vụ một nghiệp vụ chứ kh&ocirc;ng chỉ đơn giản l&agrave;m c&aacute;c dịch vụ nhỏ hơn. K&iacute;ch thước hợp l&yacute; của một service l&agrave; k&iacute;ch thước đủ để đ&aacute;p ứng y&ecirc;u cầu của một chức năng trong hệ thống.</li>
	<li>Kh&aacute;c với services trong SOA, một microservice kh&ocirc;ng n&ecirc;n c&oacute; qu&aacute; nhiều h&agrave;m hay chức năng hỗ trợ xung quanh v&agrave; định dạng th&ocirc;ng b&aacute;o/ gửi tin (messaging) phải đơn giản.</li>
	<li>Một c&aacute;ch tốt l&agrave; c&oacute; thể bắt đầu với services to c&oacute; phạm vi rộng rồi chia nhỏ dần (dựa theo nghiệp vụ thực tế của hệ thống).</li>
</ul>

Trong v&iacute; dụ về hệ thống b&aacute;n h&agrave;ng, bạn c&oacute; thể thấy ứng dụng monolithic được t&aacute;ch th&agrave;nh bốn microservices l&agrave; &ldquo;inventory&rdquo;, &ldquo;accounting&rdquo;, &ldquo;shipping&rdquo; v&agrave; &ldquo;store&rdquo;. Ch&uacute;ng giải quyết một y&ecirc;u cầu giới hạn nhất định nhưng tập trung v&agrave;o chức năng đ&oacute;. Theo đ&oacute;, mỗi service t&aacute;ch biệt ho&agrave;n to&agrave;n khỏi nhau v&agrave; đảm bảo t&iacute;nh linh hoạt v&agrave; độc lập.

Ồ, nếu t&aacute;ch c&aacute;c services ra độc lập, vậy l&agrave;m sao li&ecirc;n lạc v&agrave; trao đổi th&ocirc;ng tin/dữ liệu giữa c&aacute;c services với nhau?

<h2>Li&ecirc;n lạc giữa Microservices</h2>

Trong ứng dụng monolithic, c&aacute;c chức năng kh&aacute;c nhau nằm trong c&aacute;c component kh&aacute;c nhau được kết nối bằng c&aacute;ch gọi h&agrave;m hay phương thức. Trong SOA, việc n&agrave;y được chuyển sang một chế độ t&aacute;ch rời hơn với kiểu nhắn tin qua c&aacute;c dịch vụ web (web service messaging), phần lớn d&ugrave;ng SOAP tr&ecirc;n nền giao thức HTTP, JMS. Những webservices n&agrave;y kh&aacute; phức tạp. Như đ&atilde; n&oacute;i ở tr&ecirc;n, microservices y&ecirc;u cầu l&agrave; phải c&oacute; một cơ chế truyền tin đơn giản v&agrave; nhẹ.

Vậy đ&oacute; l&agrave; những cơ chế n&agrave;o?

<h2>&nbsp;</h2>

<h2>Gửi Tin Đồng Bộ &ndash; REST, Thrift</h2>

Với truyền tin đồng bộ (người gửi &ndash; client sẽ chờ một khoảng thời gian để nhận kết quả từ service), REST l&agrave; sự lựa chọn h&agrave;ng đầu v&igrave; n&oacute; cung cấp hệ thống truyền tin đơn giản qua giao thức HTTP dạng request &ndash; response. Do đ&oacute;, nhiều microservices sử dụng HTTP với API. Mỗi chức năng sẽ xuất ra (expose) API.

&nbsp;

Ngo&agrave;i REST, Thrift cũng được sử dụng để truyền tin đồng bộ.

<h3>Gửi Tin Bất Đồng Bộ &ndash; AMQP, STOMP, MQTT</h3>

Trong một số kịch bản, truyền tin bất đồng bộ l&agrave; cần thiết (client kh&ocirc;ng mong đợi response ngay lập tức, hoặc kh&ocirc;ng cần response). C&aacute;c giao thức truyền tin bất đồng bộ như AMQP, STOMP hay MQTT được sử dụng rộng r&atilde;i.

Như vậy l&agrave; ch&uacute;ng ta c&oacute; gửi tin nhắn đồng bộ hoặc bất đồng bộ. Nhưng n&ecirc;n định dạng cho tin nhắn thế n&agrave;o đ&acirc;y?

<h3>C&aacute;c Định Dạng Tin Nhắn &ndash; JSON, XML, Thrift, ProtoBuf, Avro</h3>

Quyết định định dạng tin nhắn ph&ugrave; hợp cho microservices cũng l&agrave; một yếu tố quan trọng. Với phần lớn c&aacute;c ứng dụng microservices, họ sử dụng những kiểu tin nhắn dạng chữ như JSON v&agrave; XML tr&ecirc;n nền giao thức HTTP với API. Trong trường hợp cần truyền tin dạng nhị ph&acirc;n, microservices c&oacute; thể d&ugrave;ng dạng Thrift, Proto hay Avro.

<h3>Service Contracts &ndash; Định Nghĩa Service Interfaces &ndash; Swagger, RAML</h3>

Khi bạn c&oacute; một nghiệp vụ được x&acirc;y dựng như một dịch vụ, bạn cần định nghĩa v&agrave; th&ocirc;ng b&aacute;o hợp đồng dịch vụ (service contract thể hiện giao k&egrave;o của service).

Bởi v&igrave; ch&uacute;ng ta x&acirc;y dựng microservices tr&ecirc;n kiểu kiến tr&uacute;c REST, ta c&oacute; thể sử dụng c&ugrave;ng kiểu REST API để định nghĩa hợp đồng của microservices. Do đ&oacute;, microservices sử dụng c&aacute;c ng&ocirc;n ngữ định nghĩa REST API ti&ecirc;u chuẩn như Swagger, RAML để định nghĩa hợp đồng dịch vụ.

Đối với trường hợp microservices kh&ocirc;ng được triển khai dựa tr&ecirc;n HTTP/REST (cụ thể l&agrave; d&ugrave;ng Thrift), ch&uacute;ng ta c&oacute; thể d&ugrave;ng mức độ giao thức &lsquo;Interface Definition Languages&rsquo; (v&iacute; dụ:&nbsp;<a href="https://thrift.apache.org/docs/idl">Thrift IDL</a>)

<h3>Kết Nối Microservices (Giao Tiếp Giữa C&aacute;c Services)</h3>

Trong kiến tr&uacute;c microservices, ứng dụng phần mềm được cấu th&agrave;nh từ c&aacute;c dịch vụ độc lập. Để ho&agrave;n th&agrave;nh một t&aacute;c vụ của người d&ugrave;ng tr&ecirc;n phần mềm, kết nối v&agrave; giao tiếp giữa c&aacute;c microservices l&agrave; cần thiết v&igrave; t&aacute;c vụ gồm nhiều t&aacute;c động kh&aacute;c nhau l&ecirc;n c&aacute;c services. V&igrave; vậy, giao tiếp giữa c&aacute;c microservices l&agrave; một vấn đề cực k&igrave; quan trọng.

Khi &aacute;p dụng SOA, giao tiếp giữa c&aacute;c services được tiến h&agrave;nh bởi một Enterprise Service Bus (ESB) v&agrave; phần lớn logic nằm trong tầng trung gian n&agrave;y (định tuyến cho tin nhắn, chuyển đổi v&agrave; điều phối tin nhắn). Tuy nhi&ecirc;n, kiến tr&uacute;c microservices th&uacute;c đẩy việc loại trừ một tầng giao tiếp trung gian tập trung/ ESB v&agrave; chuyển phần &lsquo;smart-ness&rsquo; hay business logic sang c&aacute;c services (n&oacute; được gọi l&agrave; &lsquo;Smart Endpoints&rsquo;).

Bởi v&igrave; microservices sử dụng giao thức ti&ecirc;u chuẩn như HTTP/REST, JSON, &hellip;, Cho n&ecirc;n c&aacute;c giao tiếp giữa c&aacute;c microservices được cố gắng thống nhất về giao thức v&agrave; hạn chế tối đa việc t&iacute;ch hợp với một giao thức kh&aacute;c. Một lựa chọn kh&aacute;c cho giao tiếp giữa microservices l&agrave; sử dụng một message bus nhẹ hay gateway với khả năng định tuyến tối thiểu hoạt động như những đường truyền đơn thuần kh&ocirc;ng xử l&yacute; business logic g&igrave; hết (dump pipe). Dựa v&agrave;o những phong c&aacute;ch n&agrave;y, c&oacute; một số kiểu mẫu giao tiếp trong microservices như dưới đ&acirc;y.

<h3>Point-to-point &ndash; Kết Nối Trực Tiếp Giữa C&aacute;c Services</h3>

Với kiểu kết nối trực tiếp điểm nối điểm, to&agrave;n bộ logic của việc định tuyến truyền tin nhắn nằm trong mỗi điểm cuối (endpoint) hay ch&iacute;nh l&agrave; c&aacute;c services. V&agrave; services n&oacute;i chuyện trực tiếp với nhau. Mỗi service mở ra một REST APIs v&agrave; bất k&igrave; service hay kh&aacute;ch h&agrave;ng b&ecirc;n ngo&agrave;i n&agrave;o cũng c&oacute; thể gọi service qua REST API của n&oacute;.

<img alt="" height="399" src="https://uat.admin.careers.saigontechnology.vn/ckfinder/userfiles/images/microservices-logical.png" width="987" />

R&otilde; r&agrave;ng l&agrave; m&ocirc; h&igrave;nh n&agrave;y đơn giản v&agrave; hoạt động ổn với ứng dụng microservices tương đối nhỏ nhưng khi số lượng services tăng l&ecirc;n, việc giao tiếp trở n&ecirc;n cực phức tạp. Đ&acirc;y l&agrave; l&yacute; do trong m&ocirc; h&igrave;nh SOA truyền thống người ta sử dụng Enterprise Service Bus (ESB), ch&iacute;nh l&agrave; để loại bỏ kết nối trực tiếp phức tạp v&agrave; rối rắm. Sau đ&acirc;y l&agrave; một số nhược điểm của kiểu giao tiếp trực tiếp (point to point).

<ul>
	<li>Những y&ecirc;u cầu như x&aacute;c thực người d&ugrave;ng, điều tiết, gi&aacute;m s&aacute;t,&hellip;phải được thực hiện (implement) ở mọi microservices.</li>
	<li>Việc tr&ecirc;n dẫn đến c&aacute;c t&iacute;nh năng phổ biến bị tr&ugrave;ng lặp, việc thực hiện mỗi microservices c&oacute; thể trở n&ecirc;n phức tạp.</li>
	<li>Kh&ocirc;ng c&oacute; c&aacute;ch quản l&yacute;, kiểm so&aacute;t giao tiếp giữa c&aacute;c services (chẳng hạn như muốn theo d&otilde;i, truy t&igrave;m hay lọc c&aacute;c giao h&agrave;nh động giữa c&aacute;c services).</li>
	<li>Thường việc kết nối trực tiếp trong microservices được coi l&agrave;&nbsp;<a href="https://www.infoq.com/articles/seven-uservices-antipatterns">anti-pattern</a>&nbsp;cho việc triển khai c&aacute;c ứng dụng microservice c&oacute; quy m&ocirc; lớn.</li>
</ul>

V&igrave; vậy, với những trường hợp phức tạp hơn, thay v&igrave; kết nối trực tiếp hay d&ugrave;ng một ESB trung t&acirc;m, ch&uacute;ng ta c&oacute; thể sử dụng 1&nbsp;messaging bus&nbsp;trung t&acirc;m gọn nhẹ. N&oacute; cung cấp một lớp trừu tượng h&oacute;a c&aacute;c microservices (an abstraction layer). C&aacute;ch n&agrave;y được gọi l&agrave; API Gateway.

Bạn có thể xây dựng ứng dụng mới với microservices hoặc chuyển đổi ứng dụng sẵn có sang microservices. Với cách nào thì việc quyết định kích cỡ, phạm vi và tính năng của microservices rất quan trọng. Có thể đây chính là phần khó nhất bạn gặp phải khi phát triển hệ thống microservices trong thực tế.

Microservices: Cưỡi ngựa xem hoa - Phần 2

<h2>API-Gateway</h2>

Nh&igrave;n chung, một API Gateway cho ph&eacute;p bạn sử dụng một API được quản l&yacute; qua HTTP/REST. V&igrave; thế, ch&uacute;ng ta c&oacute; thể cung cấp tất cả c&aacute;c chức năng nghiệp vụ được ph&aacute;t triển th&agrave;nh microservices qua API Gateway như một APIs tập trung được quản l&yacute;.

<img alt="" height="294" src="/ckfinder/userfiles/images/image-20220905140348-1.png" width="659" />

Trong v&iacute; dụ b&aacute;n h&agrave;ng của ch&uacute;ng ta, theo&nbsp;H&igrave;nh 5&nbsp;tất cả microservices đều được xuất ra th&ocirc;ng qua API Gateway v&agrave; đ&acirc;y l&agrave; một chốt đầu v&agrave;o duy nhất cho người d&ugrave;ng. Nếu một microservice muốn giao tiếp với một microservice kh&aacute;c th&igrave; cần đi qua API Gateway.

API Gateway cung cấp c&aacute;c lợi thế dưới đ&acirc;y:

<ul>
	<li>Cung cấp một lớp trừu tượng h&oacute;a c&aacute;c microservices. V&iacute; dụ thay v&igrave; cung cấp một API cho tất cả kh&aacute;ch h&agrave;ng, API gateway c&oacute; thể xuất ra hay hiển thị API kh&aacute;c nhau cho mỗi kh&aacute;ch h&agrave;ng.</li>
	<li>Định tuyến v&agrave; chuyển đổi tin nhắn gọn nhẹ ở cấp gateway.</li>
	<li>Một điểm tập trung cho c&aacute;c chức năng chung kh&ocirc;ng mang t&iacute;nh nghiệp vụ kinh doanh như bảo mật, gi&aacute;m s&aacute;t v&agrave; điều tiết.</li>
	<li>Với API Gateway, microservices trở n&ecirc;n c&agrave;ng gọn nhẹ v&igrave; c&aacute;c chức năng chung kh&ocirc;ng mang t&iacute;nh nghiệp vụ đều chuyển sang Gateway.</li>
</ul>

API Gateway c&oacute; thể l&agrave; kiểu mẫu được sử dụng rộng r&atilde;i nhất trong triển khai microservices.

<h2>Message Broker &ndash; Người truyền tin trung gian</h2>

Microservices c&oacute; thể được kết nối qua truyền tin bất đồng bộ như y&ecirc;u cầu một chiều (requests) hay th&ocirc;ng b&aacute;o/ đăng k&iacute; nhận th&ocirc;ng b&aacute;o (publish/ subscribe) qua queues hay topics. Với publish/ subscribe, một service c&oacute; thể tạo tin nhắn v&agrave; gửi bất đồng bộ đến một h&agrave;ng chờ (queue hay topic). Sau đ&oacute; service kh&aacute;c c&oacute; thể nhận tin n&agrave;y từ queue hay topic. Phong c&aacute;ch n&agrave;y t&aacute;ch biệt người gửi v&agrave; người nhận, v&agrave; người truyền tin trung gian sẽ lưu tin nhắn đến khi người nhận c&oacute; thể xử l&yacute;. Người gửi ho&agrave;n to&agrave;n kh&ocirc;ng biết g&igrave; về người nhận.

<img alt="" height="286" src="/ckfinder/userfiles/images/image-20220905140401-2.png" width="658" />

Giao tiếp giữa người gửi/ người nhận được tạo ra bởi&nbsp;message broker&nbsp;qua c&aacute;c ti&ecirc;u chuẩn truyền tin bất đồng bộ như AMQP, MQTT,&hellip;

<h2>Quản L&yacute; Cơ Sở Dữ Liệu Ph&acirc;n T&aacute;n</h2>

Trong cấu tr&uacute;c monolithic, ứng dụng lưu dữ liệu v&agrave;o một cơ sở dữ liệu (CSDL) tập trung duy nhất.

<img alt="" height="265" src="/ckfinder/userfiles/images/image-20220905140421-3.png" width="419" />

Trong microservices, c&aacute;c chức năng được t&aacute;ch th&agrave;nh nhiều microservices v&agrave; nếu sử dụng c&ugrave;ng một CSDL trung t&acirc;m th&igrave; microservices kh&ocirc;ng c&ograve;n độc lập. Thay đổi dữ liệu của một service c&oacute; thể l&agrave;m hỏng c&aacute;c services kh&aacute;c. Do đ&oacute;, mỗi microservice phải c&oacute; CSDL ri&ecirc;ng.

<img alt="" height="249" src="/ckfinder/userfiles/images/image-20220905140439-4.png" width="413" />

Dưới đ&acirc;y l&agrave; v&agrave;i đặc điểm ch&iacute;nh khi ph&aacute;t triển việc quản l&yacute; dữ liệu ph&acirc;n t&aacute;n trong kiến tr&uacute;c microservices.

<ul>
	<li>Mỗi service c&oacute; thể c&oacute; một CSDL ri&ecirc;ng biệt để lưu trữ th&ocirc;ng tin cần thiết cho nghiệp vụ của service đ&oacute;.</li>
	<li>Một microservice chỉ c&oacute; thể truy xuất v&agrave;o CSDL ri&ecirc;ng của n&oacute; m&agrave; kh&ocirc;ng c&oacute; quyền truy xuất v&agrave;o CSDL của microservices kh&aacute;c.</li>
	<li>Trong một số ho&agrave;n cảnh, để ho&agrave;n th&agrave;nh một t&aacute;c vụ bạn cần phải cập nhật nhiều CSDL. Khi đ&oacute; CSDL của microservices kh&aacute;c chỉ n&ecirc;n được cập nhật qua API của những dịch vụ n&agrave;y (kh&ocirc;ng trực tiếp thay đổi CSDL).</li>
</ul>

Việc ph&acirc;n t&aacute;ch quản l&yacute; dữ liệu cho ph&eacute;p bạn ho&agrave;n to&agrave;n ph&acirc;n t&aacute;ch c&aacute;c microservices v&agrave; c&oacute; thể chọn c&aacute;c c&ocirc;ng nghệ quản l&yacute; dữ liệu kh&aacute;c nhau (SQL hay NoSQL,&hellip;nhiều CSDL kh&aacute;c nhau cho c&aacute;c microservices). Tuy nhi&ecirc;n, với c&aacute;c giao dịch phức tạp li&ecirc;n quan đến nhiều microservices, giao dịch phải được thực hiện qua API.

Ý tưởng chính của API Gateway là sử dụng một cổng truyền tin gọn nhẹ như một điểm vào chính cho tất cả khách hàng/ người dùng và triển khai những chức năng chung mà không liên quan đến nghiệp vụ đặc thù ở cấp Gateway này.

Microservices: Cưỡi ngựa xem hoa - Phần 3 (API-Gateway)

&lt;html&gt;&lt;body&gt;&lt;pre&gt;&lt;code class=&quot;language-c&quot;&gt;Quản Trị Ph&acirc;n T&aacute;n&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Kiến tr&uacute;c microservices ủng hộ quản trị ph&acirc;n t&aacute;n.&lt;/p&gt;&lt;p&gt;Nh&igrave;n chung, quản trị nghĩa l&agrave; thiết lập v&agrave; thực thi phương thức m&agrave; con người v&agrave; c&aacute;c giải ph&aacute;p l&agrave;m việc c&ugrave;ng nhau để đạt được mục ti&ecirc;u. Trong ngữ cảnh SOA, quản trị SOA (SOA governance) hướng dẫn việc ph&aacute;t triển c&aacute;c services c&oacute; thể t&aacute;i sử dụng, thiết lập c&aacute;ch services được thiết kế, ph&aacute;t triển v&agrave; c&aacute;ch ch&uacute;ng thay đổi theo thời gian. N&oacute; thiết lập một giao k&egrave;o giữa người cung cấp services v&agrave; người sử dụng services, th&ocirc;ng b&aacute;o cho người sử dụng những thứ họ c&oacute; thể nhận được v&agrave; người sử dụng những thứ họ phải cung cấp. Trong quản trị SOA, c&oacute; hai kiểu quản trị phổ biến:&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Quản trị khi thiết kế &ndash; định nghĩa v&agrave; kiểm so&aacute;t việc tạo services, thiết kế v&agrave; thực thi c&aacute;c ch&iacute;nh s&aacute;ch của services.&lt;/li&gt;&lt;li&gt;Quản trị khi triển khai/ chạy &ndash; khả năng đảm bảo c&aacute;c ch&iacute;nh s&aacute;ch của services trong qu&aacute; tr&igrave;nh hoạt động.&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&lt;i&gt;Vậy trong microservices th&igrave; quản trị l&agrave; g&igrave;?&lt;/i&gt;&lt;/p&gt;&lt;p&gt;Microservices được x&acirc;y dựng động lập v&agrave; ph&acirc;n t&aacute;n với nền tảng c&ocirc;ng nghệ kh&aacute;c nhau. Do đ&oacute;, việc thiết lập một ti&ecirc;u chuẩn thiết kế v&agrave; ph&aacute;t triển chung l&agrave; kh&ocirc;ng cần thiết. Ch&uacute;ng ta c&oacute; thể kết luận về khả năng quản trị ph&acirc;n t&aacute;n trong kiến tr&uacute;c microservices như sau:&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Kh&ocirc;ng cần phải c&oacute; một hệ quản trị tập trung khi thiết kế.&lt;/li&gt;&lt;li&gt;Microservices c&oacute; thể tự quyết định thiết kế v&agrave; ph&aacute;t triển của n&oacute;.&lt;/li&gt;&lt;li&gt;Kiến tr&uacute;c ủng hộ v&agrave; hỗ trợ việc chia sẻ c&aacute;c services chung hay c&oacute; thể t&aacute;i sử dụng.&lt;/li&gt;&lt;li&gt;Một số mặt của quản trị trong qu&aacute; tr&igrave;nh hoạt động như SLAs, điều phối, gi&aacute;m s&aacute;t, bảo mật hay t&igrave;m kiếm dịch vụ (service discovery) c&oacute; thể được ph&aacute;t triển ở cấp API Gateway.&lt;/li&gt;&lt;/ul&gt;&lt;h3&gt;&lt;strong&gt;Service Registry &amp;amp; Service Discorvery (Truy T&igrave;m Dịch Vụ).&lt;/strong&gt;&lt;/h3&gt;&lt;p&gt;Trong microservices, số lượng services m&agrave; bạn cần xử l&yacute; kh&aacute; lớn. V&agrave; địa điểm của ch&uacute;ng c&oacute; thể thay đổi nhanh v&agrave; thường xuy&ecirc;n v&igrave; t&iacute;nh chất của việc ph&aacute;t triển microservices l&agrave; nhanh. N&ecirc;n bạn cần phải x&aacute;c định được vị tr&iacute; của một service trong qu&aacute; tr&igrave;nh chạy. Giải ph&aacute;p cho vấn đề n&agrave;y l&agrave; Service Registry.&lt;/p&gt;&lt;h3&gt;&lt;strong&gt;Service Registry&lt;/strong&gt;&lt;/h3&gt;&lt;p&gt;Service Registry giữ c&aacute;c thực thể microservices v&agrave; địa chỉ của ch&uacute;ng. Thực thể microservices được đăng k&iacute; với service registery khi bắt đầu chạy v&agrave; hủy đăng k&iacute; khi tắt. Người d&ugrave;ng c&oacute; thể t&igrave;m c&aacute;c services đang tồn tại v&agrave; địa chỉ của ch&uacute;ng qua service registry.&lt;/p&gt;&lt;h3&gt;&lt;strong&gt;Service Discovery&lt;/strong&gt;&lt;/h3&gt;&lt;p&gt;Để t&igrave;m c&aacute;c microservices đang tồn tại v&agrave; địa điểm của ch&uacute;ng, ch&uacute;ng ta cần một quy tr&igrave;nh truy t&igrave;m dịch vụ. C&oacute; hai m&ocirc; h&igrave;nh l&agrave; Client-side Discovery v&agrave; Server-side Discovery. H&atilde;y c&ugrave;ng xem x&eacute;t hai m&ocirc; h&igrave;nh n&agrave;y.&lt;/p&gt;&lt;p&gt;&lt;i&gt;Client-side Discovery&lt;/i&gt;&nbsp;&ndash; Với m&ocirc; h&igrave;nh n&agrave;y, client hay API Gateway lấy th&ocirc;ng tin địa điểm của một thực thể service bằng c&aacute;ch truy vấn Service Registry.&lt;/p&gt;&lt;p style=&quot;text-align:center;&quot;&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-dU8E9DeAowxJUvH7iVz4fjcjUHZE4xeUtfavIeEh.png&quot; alt=&quot;&quot;&gt;&lt;/p&gt;&lt;p&gt;Client hay API Gateway phải thực hiện logic t&igrave;m kiếm service bằng c&aacute;ch gọi v&agrave;o Service Registry.&lt;/p&gt;&lt;p&gt;&lt;i&gt;Server-side Discovery &ndash;&lt;/i&gt;&nbsp;Với c&aacute;ch n&agrave;y, client hay API Gateway gửi y&ecirc;u cầu l&ecirc;n một component (c&oacute; thể l&agrave; một Load Balancer). Component n&agrave;y sẽ gọi Service Registry v&agrave; quyết định địa điểm của c&aacute;c microservices.&lt;/p&gt;&lt;p style=&quot;text-align:center;&quot;&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-IhnnuxS99BATpwpcuEKQmgRNUrpZyFBmb3uaZu9d.png&quot; alt=&quot;&quot;&gt;&lt;/p&gt;&lt;p&gt;Một số giải ph&aacute;p triển khai microservices như Kubernetes cung cấp m&ocirc; h&igrave;nh server-side discovery.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Microservices: Cưỡi ngựa xem hoa - Phần 4

<h2>Deployment&nbsp;&ndash;&nbsp;Triển&nbsp;Khai Updated</h2>

Việc triển khai c&aacute;c dịch vụ c&oacute; một tr&ograve; trọng yếu v&agrave; gồm c&aacute;c y&ecirc;u cầu sau:

<ul>
	<li>Khả năng triển khai/ gỡ xuống độc lập m&agrave; kh&ocirc;ng ảnh hưởng đến dịch vụ kh&aacute;c.</li>
	<li>C&oacute; thể mở rộng theo cấp microservices, chỉ mở rộng microservices cần thiết.</li>
	<li>Ph&aacute;t triển v&agrave; triển khai microservices nhanh ch&oacute;ng.</li>
	<li>Một microservice ngắt kết nối hay sập th&igrave; kh&ocirc;ng ảnh hưởng c&aacute;c dịch vụ kh&aacute;c.</li>
</ul>

Docker&nbsp;(một c&ocirc;ng cụ m&atilde; nguồn mở cho ph&eacute;p lập tr&igrave;nh vi&ecirc;n v&agrave; quản trị vi&ecirc;n hệ thống triển khai c&aacute;c ứng dụng th&agrave;nh c&aacute;c containers tr&ecirc;n m&ocirc;i trường Linux) cung cấp một c&ocirc;ng cụ tuyệt vời để triển khai microservices đ&aacute;p ứng đủ c&aacute;c y&ecirc;u cầu tr&ecirc;n. C&aacute;c bước ch&iacute;nh gồm:

<ul>
	<li>Đ&oacute;ng g&oacute;i mỗi microservice th&agrave;nh một ảnh Docker (docker image).</li>
	<li>Triển khai mỗi thực thể của service l&agrave; một Docker container.</li>
	<li>Mở rộng dựa v&agrave;o số lượng thực thể.</li>
	<li>Ph&aacute;t triển, triển khai v&agrave; khởi động microservices trở n&ecirc;n nhanh hơn với Docker (nhanh hơn nhiều c&aacute;c m&aacute;y ảo th&ocirc;ng thường &ndash; VM).</li>
</ul>

Kubernetes&nbsp;mở rộng khả năng của Docker bằng c&aacute;ch quản l&yacute; một cụm c&aacute;c Linux container như một hệ thống duy nhất, quản l&yacute; v&agrave; chạy c&aacute;c Docker containers tr&ecirc;n nhiều hosts, cung cấp service discovery v&agrave; kiểm so&aacute;t việc nh&acirc;n rộng. Như bạn c&oacute; thể thấy, những t&iacute;nh năng n&agrave;y cần thiết cho kiến tr&uacute;c microservices. V&igrave; vậy sử dụng&nbsp;Kurbernetes&nbsp;(tr&ecirc;n nền Docker) để triển khai microservices đang trở th&agrave;nh một phương ph&aacute;p cực k&igrave; hữu dụng, đặc biệt với ứng dụng lớn.

<img alt="" height="419" src="/ckfinder/userfiles/images/image-20220905140709-1.png" width="382" />

H&igrave;nh 11&nbsp;thể hiện tổng qu&aacute;t việc triển khai c&aacute;c microservices. Mỗi thực thể của microservices được triển khai th&agrave;nh một container v&agrave; c&oacute; hai containers tr&ecirc;n mỗi host. Bạn c&oacute; thể thay đổi số lượng containers chạy tr&ecirc;n một host theo &yacute; m&igrave;nh.

<h2>Security &ndash; Bảo Mật</h2>

Bảo mật microservcies l&agrave; một y&ecirc;u cầu phổ biến trong thực tế. Trước khi n&oacute;i đến bảo mật microservices, h&atilde;y nh&igrave;n lại c&aacute;ch ch&uacute;ng ta thường thực hiện bảo mật của ứng dụng monolithic.

<ul>
	<li>Bảo mật của một ứng dụng monolithic thường l&agrave; về x&aacute;c định xem &ldquo;Ai l&agrave; người gọi đến&rdquo;, &ldquo;Người n&agrave;y c&oacute; quyền hạn g&igrave;&rdquo; v&agrave; &ldquo;Ứng dụng th&ocirc;ng b&aacute;o về những th&ocirc;ng tin n&agrave;y thế n&agrave;o&rdquo;.</li>
	<li>Một component phụ tr&aacute;ch bảo mật chung thường nằm ở đầu chuỗi xử l&yacute; y&ecirc;u cầu v&agrave; component sẽ trả về th&ocirc;ng tin cần thiết.</li>
</ul>

Vậy ch&uacute;ng ta c&oacute; thể chuyển đổi trực tiếp m&ocirc; h&igrave;nh n&agrave;y sang kiến tr&uacute;c microservices kh&ocirc;ng?

C&oacute; nhưng điều n&agrave;y y&ecirc;u cầu ph&aacute;t triển bảo mật ở từng microservices v&agrave; kết nối với một cơ sở trung t&acirc;m về người d&ugrave;ng để lấy th&ocirc;ng tin cần thiết. Đ&acirc;y l&agrave; một c&aacute;ch kh&aacute; rối rắm. Thay v&agrave;o đ&oacute;, ch&uacute;ng ta c&oacute; thể tận dụng c&aacute;c API bảo mật ti&ecirc;u chuẩn như OAuth2 v&agrave; OpenID Connect để t&igrave;m một giải ph&aacute;p tốt hơn cho vấn đề bảo mật. Trước khi n&oacute;i s&acirc;u hơn, ch&uacute;ng ta sẽ t&oacute;m tắt mục ti&ecirc;u của mỗi ti&ecirc;u chuẩn v&agrave; c&aacute;ch sử dụng ch&uacute;ng.

<ul>
	<li>OAuth2&nbsp;&ndash; một phương thức chứng thực kiểu ủy quyền. Client x&aacute;c thực với server cấp quyền (authorization server) v&agrave; nhận một token gọi l&agrave; &ldquo;Access token&rdquo;. Access token kh&ocirc;ng chứa bất k&igrave; th&ocirc;ng tin g&igrave; về client. N&oacute; chỉ l&agrave; một tấm v&eacute; tham chiếu đến th&ocirc;ng tin người d&ugrave;ng m&agrave; server cấp quyền c&oacute; thể truy xuất đến. Do đ&oacute;, đ&acirc;y cũng được gọi l&agrave; token kiểu tham chiếu &ldquo;by-reference token&rdquo; v&agrave; an to&agrave;n để sử dụng tr&ecirc;n mạng lưới mở v&agrave; internet.</li>
	<li>OpenID&nbsp;Connect&nbsp;hoạt động tương tự OAuth nhưng ngo&agrave;i Access Token, server cấp quyền c&ograve;n ph&aacute;t một ID token chứa th&ocirc;ng tin người d&ugrave;ng. Token n&agrave;y thường dạng JWT (JSON Web Token) v&agrave; được k&iacute; bởi server cấp quyền. JWT token do đ&oacute; được coi l&agrave; token kiểu tham trị &ldquo;by-value token&rdquo; bởi v&igrave; n&oacute; chứa th&ocirc;ng tin về người d&ugrave;ng v&agrave; c&oacute; thể trở n&ecirc;n kh&ocirc;ng an to&agrave;n.</li>
</ul>

B&acirc;y giờ, h&atilde;y xem x&eacute;t những ti&ecirc;u chuẩn n&agrave;y c&oacute; thể bảo mật microservices trong v&iacute; dụ b&aacute;n h&agrave;ng của ch&uacute;ng ta như thế n&agrave;o.

<img alt="" height="346" src="/ckfinder/userfiles/images/image-20220905140749-2.png" width="759" />

Như h&igrave;nh tr&ecirc;n, c&aacute;c bước ch&iacute;nh để thực hiện bảo mật microservices gồm:

<ul>
	<li>Chuyển việc x&aacute;c thực cho server dạng OAuth v&agrave; OpenID Connect (Authorization server).</li>
	<li>Sử dụng API Gateway để c&oacute; một điểm đầu v&agrave;o duy nhất cho y&ecirc;u cầu từ clients.</li>
	<li>Client kết nối với server cấp quyền v&agrave; nhận Access token. Sau đ&oacute; gửi token n&agrave;y đến API Gateway c&ugrave;ng với y&ecirc;u cầu.</li>
	<li>Dịch token tại Gateway &ndash; API Gateway lấy ra access token v&agrave; gửi đến server cấp quyền để lấy JWT.</li>
	<li>Gateway truyền JWT c&ugrave;ng với y&ecirc;u cầu đến microservices.</li>
	<li>JWT chứa th&ocirc;ng tin người d&ugrave;ng cần thiết để lưu user sessions,&hellip;.</li>
	<li>Ở mỗi lớp microservice, bạn c&oacute; thể c&oacute; một component xử l&yacute; JWT, việc n&agrave;y kh&aacute;c đơn giản. 
	https://lh4.googleusercontent.com/JDjSmaNIR-Px5svzdyVwpGd9B6S8vaCt0sWMxGjpkHOm-u6Q4lmJhVrRwq3oz8MGu3QrfyqjrrDo4CZUtgIa6d97ig</li>
</ul>

Deployment – Triển Khai và Security - Bảo mật trong kiến trúc Microservices.

Microservices: Cưỡi ngựa xem hoa - Phần 5

&lt;html&gt;&lt;body&gt;&lt;h2&gt;&lt;strong&gt;Transactions&nbsp;&ndash; C&aacute;c giao dịch Updated Again&lt;/strong&gt;&lt;/h2&gt;&lt;p&gt;&lt;i&gt;C&aacute;c transactions (giao dịch) trong microservices được hỗ trợ thế n&agrave;o (Updated) ?&lt;/i&gt;&lt;/p&gt;&lt;h6&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-SwW5F8BxhBiT42Xmstbtq4JYFvW4lWo2TpOGt4gz.png&quot;&gt;&lt;/h6&gt;&lt;figure class=&quot;image&quot;&gt;&lt;img src=&quot;https://uat.api.careers.saigontechnology.vn/storage/ck-editor/CKEDITOR-b18onTW5VKQx5jfv8rW4eFkcgyxM5MNkXOoHzS0L.png&quot;&gt;&lt;figcaption&gt;captionnnnn&lt;/figcaption&gt;&lt;/figure&gt;&lt;p&gt;Tr&ecirc;n thực tế, hỗ trợ c&aacute;c giao dịch ph&acirc;n t&aacute;n tr&ecirc;n nhiều microservices l&agrave; một nhiệm vụ đặc biệt phức tạp. Kiến tr&uacute;c microservice tự khuyến kh&iacute;ch sự phối hợp kh&ocirc;ng c&oacute; giao dịch giữa c&aacute;c dịch vụ.&lt;/p&gt;&lt;p&gt;&Yacute; tưởng l&agrave; một dịch vụ nhất định ho&agrave;n to&agrave;n kh&eacute;p k&iacute;n v&agrave; dựa tr&ecirc;n nguy&ecirc;n l&yacute; Single Responsibility Principle.&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;Việc cần phải c&oacute; c&aacute;c giao dịch ph&acirc;n t&aacute;n tr&ecirc;n nhiều microservice thường l&agrave; một triệu chứng của lỗ hổng thiết kế trong kiến ​​tr&uacute;c microservice v&agrave; thường c&oacute; thể được sắp xếp bằng c&aacute;ch t&aacute;i cấu tr&uacute;c phạm vi của microservice.&lt;/p&gt;&lt;p&gt;Tuy nhi&ecirc;n, nếu c&oacute; một y&ecirc;u cầu bắt buộc l&agrave; phải c&oacute; c&aacute;c giao dịch ph&acirc;n t&aacute;n tr&ecirc;n nhiều dịch vụ, th&igrave; c&aacute;c kịch bản như vậy c&oacute; thể được thực hiện với &lsquo;compensating operations&rsquo; (c&aacute;c hoạt động b&ugrave; ) ở cấp độ mỗi dịch vụ.&lt;/p&gt;&lt;p&gt;&Yacute; tưởng ch&iacute;nh l&agrave;, một microservice cụ thể dựa tr&ecirc;n nguy&ecirc;n l&yacute; Single Responsibility Principle v&agrave; nếu một microservice n&agrave;o đ&oacute; kh&ocirc;ng thực hiện được nhiệm vụ đ&atilde; giao, ch&uacute;ng ta c&oacute; thể coi đ&oacute; l&agrave; một thất bại của to&agrave;n bộ microservice đ&oacute;. Sau đ&oacute;, tất cả c&aacute;c hoạt động kh&aacute;c&nbsp;&lt;br&gt;(c&aacute;c hoạt động ở cấp tr&ecirc;n) phải được ho&agrave;n t&aacute;c bằng c&aacute;ch gọi hoạt động b&ugrave; tương ứng của c&aacute;c dịch vụ si&ecirc;u nhỏ đ&oacute;.&lt;/p&gt;&lt;h2&gt;&lt;strong&gt;Design for Failures &ndash; Thiết Kế Cho C&aacute;c Thất Bại&lt;/strong&gt;&lt;/h2&gt;&lt;p&gt;Kiến tr&uacute;c microservices tăng khả năng xảy ra thất bại tại microservices. Một microservice c&oacute; thể sập do một vấn đề mạng, nguồn t&agrave;i nguy&ecirc;n bị thiếu hụt hoặc kh&ocirc;ng sẵn s&agrave;ng,&hellip; Một microservice kh&ocirc;ng đ&aacute;p ứng lại th&igrave; kh&ocirc;ng n&ecirc;n dẫn đến to&agrave;n bộ ứng dụng microservices sập. Do đ&oacute;, mỗi microservices n&ecirc;n c&oacute; khả năng chịu lỗi v&agrave; hồi phục khi c&oacute; thể. Người d&ugrave;ng phải c&oacute; trải nghiệm tốt, nhẹ nh&agrave;ng v&agrave; kh&ocirc;ng nhận ra lỗi b&ecirc;n trong hệ thống.&lt;/p&gt;&lt;p&gt;Th&ecirc;m nữa, v&igrave; c&aacute;c dịch vụ c&oacute; thể gặp lỗi bất cứ l&uacute;c n&agrave;o, việc ph&aacute;t hiện (gi&aacute;m s&aacute;t thời gian thực) lỗi nhanh ch&oacute;ng v&agrave; nếu c&oacute; thể tự động phục hồi dịch vụ l&agrave; cực k&igrave; quan trọng.&lt;/p&gt;&lt;p&gt;C&oacute; một v&agrave;i kiểu mẫu xử l&yacute; lỗi trong microservices phổ biến.&lt;/p&gt;&lt;h3&gt;&lt;i&gt;&lt;strong&gt;Circuit Breaker&lt;/strong&gt;&lt;/i&gt;&lt;/h3&gt;&lt;p&gt;Khi c&oacute; lời gọi từ b&ecirc;n ngo&agrave;i đến một microservice, bạn c&oacute; thể cấu h&igrave;nh một component gi&aacute;m s&aacute;t lỗi với mỗi lời gọi. Component n&agrave;y đếm số y&ecirc;u cầu th&agrave;nh c&ocirc;ng v&agrave; thất bại, khi lỗi đạt một giới hạn nhất định th&igrave; component n&agrave;y sẽ dừng hoạt động của service (ngắt giao mạch).&lt;/p&gt;&lt;p&gt;C&aacute;ch n&agrave;y hữu dụng để tr&aacute;nh ti&ecirc;u tốn t&agrave;i nguy&ecirc;n kh&ocirc;ng cần thiết, y&ecirc;u cầu bị chậm v&igrave; timeouts, c&aacute;ch n&agrave;y cũng gi&uacute;p gi&aacute;m s&aacute;t hệ thống.&lt;/p&gt;&lt;h3&gt;&lt;i&gt;&lt;strong&gt;Bulkhead&lt;/strong&gt;&lt;/i&gt;&lt;/h3&gt;&lt;p&gt;V&igrave; một ứng dụng kiến tr&uacute;c microservices bao gồm nhiều microservices, một service dừng hoạt động kh&ocirc;ng n&ecirc;n ảnh hưởng đến phần c&ograve;n lại. Kiểu mẫu bulkhead t&aacute;ch biệt c&aacute;c phần của ứng dụng để khi c&oacute; lỗi tại một nơi n&agrave;o đ&oacute; th&igrave; kh&ocirc;ng ảnh hưởng hệ thống.&lt;/p&gt;&lt;h3&gt;&lt;i&gt;&lt;strong&gt;Timeout&lt;/strong&gt;&lt;/i&gt;&lt;/h3&gt;&lt;p&gt;Kiểu mẫu timeout l&agrave; một quy tr&igrave;nh cho ph&eacute;p dừng một y&ecirc;u cầu khi thời gian chờ đợi vượt qu&aacute; hạn mức. Bạn c&oacute; thể cấu h&igrave;nh khung thời gian t&ugrave;y &yacute;.&lt;/p&gt;&lt;p&gt;&lt;i&gt;Vậy khi n&agrave;o ch&uacute;ng ta sử dụng những kiểu mẫu n&agrave;y?&lt;/i&gt;&lt;/p&gt;&lt;p&gt;Trong phần lớn trường hợp, những kiểu mẫu n&agrave;y được &aacute;p dụng ở lớp Gateway. Khi microservices kh&ocirc;ng đ&aacute;p lại hay kh&ocirc;ng sẵn s&agrave;ng, ở cấp Gateway ch&uacute;ng ta c&oacute; thể quyết định c&oacute; n&ecirc;n gửi y&ecirc;u cầu đến microservices sử dụng circuit breakers hay timeout. Hơn nữa, sử dụng bulkhead ở Gateway kh&aacute; quan trọng v&igrave; đ&acirc;y l&agrave; một điểm đầu v&agrave;o cho tất cả y&ecirc;u cầu từ clients, n&ecirc;n nếu lỗi một service cũng kh&ocirc;ng ảnh hưởng đến việc gửi y&ecirc;u cầu đến c&aacute;c services kh&aacute;c.&lt;/p&gt;&lt;p&gt;Th&ecirc;m v&agrave;o đ&oacute;, Gateway c&oacute; thể được sử dụng như một điểm trung t&acirc;m ta c&oacute; thể lấy th&ocirc;ng tin về trạng th&aacute;i v&agrave; theo d&otilde;i c&aacute;c microservices hoạt động.&lt;/p&gt;&lt;h2&gt;&lt;strong&gt;Microservices, T&iacute;ch Hợp Cho Doanh Nghiệp, Quản L&yacute; API v&agrave; hơn thế nữa&lt;/strong&gt;&lt;/h2&gt;&lt;p&gt;Ch&uacute;ng ta đ&atilde; trao đổi c&aacute;c đặc t&iacute;nh của kiến tr&uacute;c Microservices v&agrave; c&aacute;ch bạn c&oacute; thể thực hiện ch&uacute;ng. Tuy nhi&ecirc;n, bạn n&ecirc;n lưu &yacute; rằng Microservices kh&ocirc;ng phải toa thuốc chữa b&aacute;ch bệnh. Việc &aacute;p dụng m&ugrave; qu&aacute;ng những kh&aacute;i niệm đang nổi sẽ kh&ocirc;ng xử l&yacute; vấn đề thực tế của bạn. Nếu bạn đ&atilde; đọc to&agrave;n bộ b&agrave;i n&agrave;y th&igrave; bạn sẽ thấy Microservices c&oacute; nhiều lợi &iacute;ch v&agrave; ch&uacute;ng ta n&ecirc;n tận dụng. Tuy nhi&ecirc;n, bạn cần hiểu rằng mong chờ microservices giải quyết tất cả c&aacute;c vấn đề l&agrave; kh&ocirc;ng thực tiễn.&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Transactions – Các giao dịch, Design for Failures – Thiết Kế Cho Các Thất Bại, Microservices, Tích Hợp Cho Doanh Nghiệp, Quản Lý API và hơn thế nữa.....

Interface và Abstract class, tại sao thế này và tại sao thế kia?

Related articles

OTHER ARTICLES FROM JIMMY