ﻣﻘﺪﻣﻪ

ﺩﺭ ﺟﻬﺎﻥ ﭘﻴﭽﻴﺪﻩ ﺷﺪﻩ ﺍﻣﺮﻭﺯ ﻣﻌﻤﺎﺭﻱ ، ﺗﻜﻨﻮﻟﻮﮊﻱ ﻫﺎ ﻭ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺑﺮﺍﻱ ﺣﻞ ﺍﻳﻦ ﭘﻴﭽﻴﺪﮔﻲ ﻫﺎ ﻣﻄﺮﺡ ﺷﺪﻩ ﺍ ﺳﺖ. ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣ ﺴﻠﻪ ﻣﻤﻜﻦ ﺍ ﺳﺖ ﺷﻤﺎ ﺍﺯ ﻳﻚ ﺭﺍ ﻩ ﺣﻞ ﻛﺎﻣﻼ ﻣﺘﻔﺎﻭﺕ ﺍﺯ ﺭﺍﻩ ﺣﻞ ﻫﺎﻱ ﭘﻴ ﺸﻴﻦ ﻋﻤﻞ ﻧﻤﺎﻳﻴﺪ ﻭ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻛﺎﻣﻼ ﻣﺘﻔﺎﻭﺗﻲ ﺑﻬﺮ ﺑﺒﺮﻳﺪ .ﻫﺮ ﭼﻘﺪﺭ ﺩﺭﻙ ﺩﺭ ﺳﺘﻲ ﺍﺯ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﻱ ﻣ ﺴﻠﻪ ﻭ ﻛﺎﺭﺑﺮﺩ ﺍﻳﻦ ﺍﺑﺰﺍﺭﻫﺎ ﺩﺍ ﺷﺘﻪ ﺑﺎ ﺷ ﺸﻴﻢ ( ﻧﻘﺎﻁ ﻗﻮﺕ ﻭ ﺿﻌﻴﻒ ﺁﻥ ﺭﺍ ﺑ ﺸﻨﺎ ﺳﻴﻢ) ﺣﺘﻤﺎ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺁﻧﻬﺎ ﺩﺭ ﺣﻞ ﻣﺴﺎﺋﻞ ﺩﻗﻴﻖ ﺗﺮ ﻭ ﺩﺭﺳﺖ ﻋﻤﻞ ﻣﻲ ﻧﻤﺎﻳﻴﻢ ﻭ ﺩﺭ ﻧﻬﺎﻳﺖ ﺑﻪ ﻧﺘﻴﺠﻪ ﻣﻄﻠﻮﺏ ﺩﺳﺖ ﺧﻮﺍﻫﻴﻢ ﻳﺎﻓﺖ.

ﻳﻜﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻫﺎﻱ ﻣﻄﺮﺡ ﺷﺪﻩ ﻣﻌﻤﺎﺭﻱ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﺍﺳﺖ ﻛﻪ ﺑﺴﻴﺎﺭ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﺳﺖ ﻭ ﺩﺭ ﭘﺮﻭﮊ ﻫﺎ ﺑﺴﻴﺎﺭ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻭﺍﻗﻊ ﻣﻲ ﺷﻮﺩ. ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺗﻤﺮﻛﺰ ﻣﺎ ﺑﺮ ﺭﻭﻱ ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻣﻲ ﺑﺎ ﺷﺪ ﻭ ﻧﻜﺎﺗﻲ ﻛﻪ ﺩﺭ ﺍ ﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺎﻳﺪ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ ﻭ ﻣﺸﻜﻼﺗﻲ ﻛﻪ ﺩﺭ ﺭﺍﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺷﻤﺎ ﺭﺍ ﺗﺤﺪﻳﺪ ﻭ ﺩﺭ ﻣﻘﺎﺑﻞ ﻣﺰﺍﻳﺎﻫﺎﻱ ﻛﻪ ﺑﺪﺳﺖ ﺧﻮﺍﻫﻴﻢ ﺁﻭﺭﺩ ﺭﺍ ﺑﺮﺭﺳﻲ ﺧﻮﺍﻫﻴﻢ ﻧﻤﻮﺩ.

ﺩﺭ ﻃﻮﻝ ﻣﻘﺎﻟﻪ ﻓﺮﺽ ﻣﺎ ﻛﺎﺭ ﻛﺮﺩﻥ ﺑﻪ ﺭﻭﻱ ﻳﻚ ﭘﺮﻭﮊﻩ Core banking ﺑﻪ ﺻـﻮﺭﺕ ﻳﻜﭙﺎﺭﭼﻪ ﻣﻲ ﺑﺎﺷـﺪ ﻭ ﻣﺸـﻜﻼﺗﻲ ﻛﻪ ﺑﺎ ﺁﻥ ﺭﻭﺑﺮﻭ ﺧﻮﺍﻫﻴﻢ ﺷﺪ ﻭ ﺍﻳﻨﻜﻪ ﭼﮕﻮﻧﻪ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻣﺎ ﻛﻤﻚ ﺧﻮﺍﻫﺪ ﻛﺮﺩ ﺭﺍ ﺑﺮﺭﺳﻲ ﺧﻮﺍﻫﻴﻢ ﻧﻤﻮﺩ.

ﺗﻌﺮﻳﻒ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ

ﺑﺎ ﺗﻮﺟﻪ ﻓﺮﺿـﻲ ﻛﻪ ﻣﻄﺮﺡ ﻧﻤﻮﺩﻡ ﻣﺎ ﺑﺮ ﻛﺎﺭ ﺑﺮﻭﻱ ﻳﻚ ﭘﺮﻭﮊﻩ ﺑﺎﻧﻜﻲ ﻳﻜﭙﺎﺭﭼﻪ ﻣﺸـﻐﻮﻝ ﺑﻪ ﻛﺎﺭ ﻫﺴـﺘﻴﻢ ﺍﻣﺎ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﺎ ﻣﺸـﻜﻼﺕ ﻣﺘﻔﺎﻭﺗﻲ ﺭﻭﺑﺮﻭ ﺧﻮﺍﻫﻴﻢ ﺷﺪ ﺍﺯ ﻗﺒﻴﻞ ﻧ ﺴﺨﻪ ﮔﺬﺍﺭﻱ ﻭ ﻳﺎ ﺩﺭ ﻣﺒﺎﺣﺚ ﻣﻘﺎﻳﺲ ﭘﺬﻳﺮﻱ ﺳﻴ ﺴﺘﻢ ﻭ ﻳﺎ ﻣﻮﺍﺭﺩﻱ ﺩﻳﮕﺮ ﻛﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺗﻮ ﺿﻴﺢ ﺁﻧﻬﺎ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﻬﻤﺘﺮﻳﻦ ﻣ ﺴﻠﻪ ﺍﻱ ﻛﻪ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﻣ ﺸﻜﻼﺕ ﻣﻲ ﺷﻮﺩ ﺩﺍ ﺷﺘﻦ ﻳﻚ ﭘﺮﻭﮊﻩ ﺑ ﺴﻴﺎﺭ ﺑﺰﺭﮒ ﻛﻪ ﺑ ﺼﻮﺭﺕ ﻳﻜﭙﺎﺭﭼﻪ (Monolithic) ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺷﺪﻩ ﺍﺳﺖ.ﺑﺮﺍﻱ ﺭﻫﺎ ﺷﺪﻥ ﺍﺯ ﺍﻳﻦ ﻣﺸﻜﻼﺕ ﻧﻴﺎﺯ ﺑﻪ ﺷﻜﺴﺘﻦ ﭘﺮﻭﮊﻩ ﺑﻪ ﺍﺟﺰﺍﻱ ﻛﻮﭼﻜﺘﺮﻱ ﻫﺴﺘﻴﻢ ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﭘﺮﻭﮊﻩ ﺑﺰﺭﮒ ﺑﻪ ﺑﺨﺶ ﻫﺎﻱ ﻛﻮﭼﻜﺘﺮﻱ ﺗﻘﺴـﻴﻢ ﺧﻮﺍﻫﺪ ﺷـﺪ ﻛﻪ ﻫﺮ ﺑﺨﺶ ﺑﺼـﻮﺭﺕ ﻣﺴـﺘﻘﻞ (ﺍﻧﺘﺨﺎﺏ ﺗﻜﻨﻮﻟﻮﮊﻱ،ﻣﻘﻴﺎﺱ ﭘﺬﻳﺮﺱ ،ﺍﺳـﺘﻘﺮﺍﺭ ﻧﺴـﺨﻪ ﻭ … )ﻋﻤﻞ ﺧﻮﺍﻫﺪ ﻧﻤﻮﺩ ﻭ ﻫﻤﭽﻨﻴﻦ ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺮﻭﻳﺲ ﺩﻳﮕﺮ ﺍﺟﺮﺍء ﻭ ﻳﺎ ﺍﺭﺍﺋﻪ ﺳﺮﻭﻳﺲ ﺑﻪ ﺩﻳﮕﺮ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺎ ﻭ ﻣﺸﺘﺮﻳﺎﻥ ﺍﺯ ﻳﻚ ﻣﻜﺎﻧﻴﺰﻡ ﺳﺒﻚ ﺍ ﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ.ﻣﺜﻼ ﻓﺮﺽ ﻛﻨﻴﺪ ﻣﺎﮊﻭﻝ ﻣﺜﻞ ﺳﻮﺩ،ﺗ ﺴﻬﻴﻼﺕ،ﻣ ﺸﺘﺮﻳﺎﻥ ﻭ…ﻫﺮﻳﻚ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﺟﺪﺍﮔﺎﻧﻪ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻡ.

ﺑﻨﺎﺑﺮﺍﻳﻦ ﺭﺍﻩ ﺣﻞ ﺭﺍ ﺩﺭ ﺗﻘ ﺴﻴﻢ ﺩﺍﻣﻴﻦ (domain) ﻣ ﺴﻠﻪ ﺑﻪ ﺑﺨﺶ ﺯﻳﺮ ﺩﺍﻣﻨﻪ ﻫﺎﻱ (subdomain) ﻣ ﺴﺘﻘﻠﻲ ﺩﻳﺪﻧﺪ ( ﺩﺭﺑﺎﺭﻩ ﭼﮕﻮﻧﻪ ﺍﻳﻦ ﺗﻘ ﺴﻴﻢ ﺑﻨﺪﻱ ﺍﻧﺠﺎﻡ ﻣﻲ ﺷﻮﺩ ﺑﺤﺚ ﻣﻔﺼﻠﻲ ﺍﺳﺖ ﻛﻪ ﺍﺯ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺧﺎﺭﺝ ﺍﺳﺖ) ﻛﻪ ﻫﺮ ﺯﻳﺮ ﺩﺍﻣﻴﻦ ﺑﻪ ﺻﻮﺭﺕ ﻛﺎﻣﻼ ﻣﺴﺘﻘﻞ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﺪﻩ ﻭﺩﺭ ﻧﻬﺎﻳﺖ ﺑﺮﺍﻱ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﺩﻳﮕﺮ ﺳــﺮﻭﻳﺲ ﻫﺎ ﺍﺯ ﻳﻚ ﭘﺮﻭﺗﻜﻞ ﺍﺭﺗﺒﺎﻃﻲ ﺍﺳــﺘﻔﺎﺩﻩ ﻣﻲ ﻛﻨﺪ ﺩﺭ ﻭﺍﻗﻊ ﻫﺮ ﺯﻳﺮ ﺩﺍﻣﻨﻪ ﺑﺼــﻮﺭﺕ ﻣﺴــﺘﻘﻞ ﺳــﺮﻭﻳﺲ ﻫﺎﻱ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺑﺮﺍﻱ ﺯﻳﺮ ﺩﺍﻣﻨﻪ ﻭ ﻳﺎ ﺩﻳﮕﺮ consumer ﺍﺭﺍﺋﻪ ﻣﻲ ﺩﻫﺪ ﻣﺎ ﺑﻪ ﺍﻳﻦ ﻧﮕﺮﺵ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻣﻴﮕﻮﻳﻴﻢ.

ﻣﺰﺍﻳﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ

ﺩﺭ ﺍﻳﻦ ﻗﺴﻤﺖ ﺑﻪ ﺷﻨﺎﺧﺖ ﻣﺰﺍﻳﺎﻳﻲ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ ﻭ ﻫﺮ ﻳﻚ ﺍﺯ ﻣﺰﺍﻳﺎ ﺭﺍ ﺑﺼﻮﺭﺕ ﻣﺘﻤﺮﻛﺰ ﻣﻮﺭﺩ ﺑﺤﺚ ﻗﺮﺍﺭ ﺧﻮﺍﻫﻴﻢ ﺩﺍﺩ.

  • ﺑﻬﺒﻮﺩ ﺳﺮﻋﺖ ﺍﺳﺘﻘﺮﺍﺭ ﻭﺗﺤﻮﻳﻞ ﺑﺮﻧﺎﻣﻪ ﭘﻴﭽﻴﺪﻩ ﻭ ﺑﺰﺭﮒ
  • ﻧﮕﻬﺪﺍﺭﻱ ﻭ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ
  • ﻣﻘﻴﺎﺱ ﭘﺬﻳﺮﻱ
  • ﻛﺎﻫﺶ ﻫﺰﻳﻨﻪ ﺧﻄﺎ
  • ﺗﺠﺮﺑﻪ ﺗﻜﻨﻮﻟﻮﮊﻱ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ

1. ﺑﻬﺒﻮﺩ ﺳﺮﻋﺖ ﺍﺳﺘﻘﺮﺍﺭ ﻭ ﺗﺤﻮﻳﻞ ﺑﺮﻧﺎﻣﻪ ﭘﻴﭽﻴﺪﻩ ﻭ ﺑﺰﺭﮒ

ﺩﺭ ﺟﻬﺎﻥ ﺍﻣﺮﻭﺯ ﺳﺮﻋﺖ ﺍﻧﺘﺒﺎﻕ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﻱ ﻛ ﺴﺐ ﻭ ﻛﺎﺭ ﺍﺯ ﺍﻫﻤﻴﺖ ﺧﺎ ﺻﻲ ﺑﺮﺧﻮﺩﺍﺭ ﻣﻲ ﺑﺎ ﺷﺪ ﺑﻪ ﻫﻤﻴﻦ ﺩﻟﻴﻞ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺗﻮﻟﻴﺪﻭ ﺗﻮ ﺳﻌﻪ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺍﺭﺍﺋﻪ ﺳﺮﻳﻊ ﺗﻐﻴﻴﺮﺍﺕ ﻭ ﺍﻧﺘﻘﺎﻝ ﻣﻄﻤﺌﻦ ﺁﻥ ﺑﻪ ﻣﺤﻴﻂ ﻋﻤﻠﻴﺎﺕ ﻭ ﺍﻣﻜﺎﻥ ﺍ ﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﺗﻮ ﺳﻂ ﻣ ﺸﺘﺮﻱ ﺑﺎﺭ ﺿﺮﻳﺐ ﺍﻃﻤﻴﻨﺎﻥ ﺑﺎﻻ ﻳﻜﻲ ﺍﺯ ﭼﺎﻟﺶ ﻫﺎﻱ ﻣﻬﻢ ﺩﻧﻴﺎﻳﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺍ ﺳﺖ ﺑﺪﻳﻦ ﻭ ﺳﻴﻠﻪ ﻣﻔﺎﻫﻴﻢ ﻣﻄﺮﺡ ﺷﺪ ﺑﺎ ﻧﺎﻡ DevOps ﻛﻪ ﻫﺪﻑ ﺁﻥ ﻧﺰﺩﻳﻚ ﻛﺮﺩﻥ ﺗﻴﻢ ﺗﻮ ﺳﻌﻪ ﻭ ﻋﻤﻠﻴﺎﺕ برﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﺳﺮﻋﺖ ﺑﺎﻻ ﺩﺭ ﺍﺭﺍﺋﻪ ﻭﻳﮋﮔﻲ ﻫﺎﻱ ﻛﻪ ﻣﺸﺘﺮﻱ ﺩﺭﺧﻮﺍﺳﺖ ﺩﺍﺷﺘﻪ ﻳﻌﻨﻲ ﺍﺯ ﻣﺤﻴﻂ ﺗﻮﺳﻌﻪ ﺑﻪ ﻋﻤﻠﻴﺎﺕ ﺑﺎ ﺳﺮﻋﺖ ﻭ ﺍﻃﻤﻴﻨﺎﻥ ﺑﺎﻻ.ﺍﻣﺎ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﭼﻪ ﻛﻤﻚ ﺑﻪ ﺍﻳﻦ ﻓﺮﺁﻳﻨﺪﻫﺎ ﻣﻲ ﻛﻨﺪ :

 ﺑﻴﺎﻳﺪ ﺑﺎ ﻣﺜﺎﻝ ﺟﻠﻮ ﺑﺮﻭﻳﻢ،ﻛﻪ ﺩﺭ ﻳﻚ ﭘﺮﻭﮊﻩ ﺑﺎﻧﻜﻲ ( core banking ) ﻳﻜﭙﺎﺭﭼﻪ ﻣﺸـﻐﻮﻝ ﻛﺎﺭ ﻫﺴـﺘﻴﻦ ﻭ ﺩﺭ ﻳﻚ ﻫﻤﭽﻴﻨﻴﻦ ﭘﺮﻭﮊﻩ ﻱ ﺑﺰﺭﮔﻲ ﻧﺴـﺨﻪ ﮔﺬﺍﺭﻱ ﻛﺎﺭﻱ ﺳـﺨﺖ ﻭ ﭘﻴﭽﻴﺪﻩ ﺍﺳـﺖ ﭼﺮﺍ ﺑﺮﺍﻱ ﻧﺴـﺨﻪ ﮔﺬﺍﺷـﺘﻴﻦ ﻣﺠﺒﻮﺭ ﺑﻪ ﻫﻤﺎﻫﻨﮕﻲ ﺗﻌﺪﺍﺩ ﺯﻳﺎﺩﻱ ﺍﺯ ﺍﻓﺮﺍﺩ ﺍﺯ ﺗﻴﻢ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﻫﺴﺘﻴﻦ ﺩﺭ ﺍﻳﻨﺼﻮﺭﺕ ﻧﺴﺨﻪ ﮔﺬﺍ ﺷﺘﻦ ﻛﺎﺭ ﺳﺨﺘﻲ ﻭ ﭘﺮ ﺭﻳﺴﻜﻲ ﻣﻲ ﺑﺎﺷﺪ ﺣﺎﻻ ﻣﺴﺎﺋﻠﻪ ﺭﻭ ﻛﻤﻲ ﭘﻴﭽﻴﺪﺗﺮ ﻛﻨﻴﻢ ﺩﺭ ﻧﻈﺮبگیرﻡ ﺩﺭ ﺗﻴﻤﻲ ﻫﺴﺘﻴﻦ ﻛﻪ ﻣﺸﺘﺮﻱ ﺷﻤﺎ ﻓﻴﭽﺮﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺍﺯ ﺗﻴﻢ ﺷﻤﺎ ﻣﻲ ﺧﻮﺍ ﻫﺪ ﻭ ﺷﻤﺎ ﺑﺎﻳﺪ ﻧﺴﺨﻪ ﻫﺎﻱ ﭘﻲ ﺩﺭ ﭘﻲ ﺭﺍ ﺭﻳﻠﻴﺰ ﻛﻨﻴﺪ ﻭ ﻫﺮ ﺑﺎﺭ ﺑﺮﺍﻱ ﻧﺴــﺨﻪ ﮔﺬﺍﺭﻱ ﭼﻨﻴﻦ ﻣﺸــﻜﻞ ﭘﻴﭽﻴﺪ ﻩ ﺍﻱ ﺧﻮﺍﻫﻴﺪ ﺩﺍﺷـــﺖ ﺧﻮﺏ ﺣﺎﻻ ﺭﺍﻩ ﺣﻞ ﺍﮔﺮ ﺍﻳﻦ ﺳــﻴﺴــﺘﻢ ﺑﺰﺭﮒ ﺭﺍ ﺑﻪ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻮﭼﻜﺘﺮ ﺗﻘ ﺴﻴﻢ ﻛﻨﻴﻢ ﻭ ﭘﺮﻭﮊﻩ ﺷﻤﺎ ﺑ ﺼﻮﺭﺕ ﻣ ﺴﺘﻘﻞ ﻋﻤﻞ ﻧﻤﻴﺎﺩ ﺑﺮﺍﻱ ﻧ ﺴﺨﻪ ﮔﺬﺍ ﺷﺘﻦ ﻭ ﺍﺭﺍﺋﻪ ﻓﻴﭽﺮ ﺟﺪﻳﺪ ﺑﻪ ﻣﺸـﺘﺮﻱ ﻛﺎﺭ ﺑﺴـﻴﺎﺭ ﺳـﺎﺩﻩ ﺗﺮﻱ ﺧﻮﺍﻫﻴﺪ ﺩﺍﺷـﺖ ﭼﺮﺍ ﺑﻪ ﺻـﻮﺭﺕ ﻣﺴـﺘﻘﻞ ﻋﻤﻞ ﻧﻤﻮﺩﻩ ﻭ ﺑﺮﺍﻱ ﻧﺴـﺨﻪ ﮔﺬﺍﺭﻱ ﻻﺯﻡ ﺑﻪ ﻫﻤﺎﻫﻨﮕﻲ ﻫﺎﻱ ﺯﻳﺎﺩﻱ ﻧﻴﺴﺖ ﺩﺭ ﺍﻳﻨﺼﻮﺭﺕ ﺑﺎ ﺳﺮﻋﺖ ﺑﻴﺸﺘﺮﻱ ﺗﻐﻴﻴﺮﺍﺕ ﺭﺍ ﺑﻪ ﺩﺳﺖ ﺻﺎﺣﺒﺎﻥ ﻣﺤﺼﻮﻝ ﺧﻮﺍﻫﻴﺪ ﺭﺳﺎﻧﺪ.

 ﺑﺎ ﻣﻴﻜﺮﻭﺳــﺮﻭﻳﺲ ﺷــﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﻧﺴــﺨﻪ ﻗﺎﺑﻞ ﺍﻃﻤﻴﻨﺎﻥ ﺗﺮﻱ ﺑﻪ ﻣﺸــﺘﺮﻱ ﺗﺤﻮﻳﻞ ﺑﺪﻫﻴﺪ ﺣﺎﻻ ﭼﺮﺍ؟ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﺩ ﻛﻪ ﻫﻤﺎﻥ ﭘﺮﻭﮊﻩ ﺑﺎﻧﻜﻲ ﺭﺍ ﺑﺎﻳﺪ ﺗﺴـــﺖ ﻛﻨﻴﺪ ﺣﺎﻻ ﺗﺴـــﺖ ﺑﻪ ﺷــﻜﻠﻬﺎﻱ ﻣﺨﺘﻠﻒ ﻗﻄﻌﺎ ﻛﺎﺭ ﺯﻣﺎﻥ ﺑﺮ ﻭ ﺳــﺨﺖ ﺗﺮ ﻭ ﻃﻮﻻﻧﻲ ﺗﺮ ﺧﻮﺍﻫﻲ ﺑﻮﺩ ﻭ ﺣﺎﻻ ﺍﮔﺮ ﻣﺎﻛﺮﻭﺳﺮﻭﻳﺲ ﺧﻮﺩ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻦ ﺑﻪ ﺳﺎﺩﮔﻲ ﻭ ﺯﻣﺎﻥ ﻛﻤﺘﺮ ﻭ ﻣﻨﺎﺑﻊ ﻛﻤﺘﺮ ﺍﻣﻜﺎﻥ ﺗﺴﺖ ﺑﺮﺍﻱ ﺷﻤﺎ ﻣﻬﻴﺎ ﺧﻮﺍﻫﺪ ﺑﻮﺩ.

 ﻧﻜﺘﻪ ﺁﺧﺮ ﺍﺳﺘﻘﻼﻝ ﻫﺴﺖ ﻛﻪ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﺷﺪﻥ ﺑﻪ ﻫﻤﺮﺍﻩ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ ﻭ ﺗﻤﺎﻡ ﻓﺮﺁﻳﻨﺪﻩ ﺑﺼﻮﺭﺕ ﻣﺴﺘﻘﻼ ﺍﻧﺠﺎﻡ ﺧﻮﺍﻫﺪ ﺷﺪ ﻭ ﺩﺭ

ﻧﻬﺎﻳﺖ ﺳﺮﻳﻊ ﺗﻮﺳﻌﻪ ﻫﻢ ﺑﺴﻴﺎﺭ ﺑﺎﻻﺗﺮ ﺧﻮﺍﻫﺪ ﺭﻓﺖ .


2. ﻧﮕﻬﺪﺍﺭﻱ ﻭ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎ

ﺑﻪ ﺩﻟﻴﻞ ﺗﻘ ﺴﻴﻢ ﺷﺪﻥ ﺳﻴ ﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﺑﻪ ﺍﺟﺰﺍء ﻛﻮﭼﻜﺘﺮ ﺩﺭﻙ ﻛﺪ ﻭ ﻫﻤﭽﻨﻴﻦ ﭘ ﺸﺘﻴﺎﻧﻲ ﻭ ﺍﺭﺗﻘﺎء ﺁﻥ ﻧﻴﺰ ﺳﺎﺩﻩ ﺗﺮ ﺧﻮﺍﻫﺪ ﺷﺪ ﺑﻪ ﺩﻟﻴﻞ ﺍﻳﻨﻜﻪ ﺷﻤﺎ ﺑﺎ ﺣﺠﻢ ﺯﻳﺎﺩﻱ ﺍﺯ ﻛﺪﻫﺎ ﺭﻭﺑﺮﻭ ﻧﺨﻮﺍﻫﻴﺪ ﺑﻮﺩ ﻭ ﺑﺮ ﺑﺨﺸﻲ ﻛﻮﭼﻜﺘﺮﻱ ﺍﺯ ﺁﻥ ﺗﻤﺮﻛﺰ ﺧﻮﺍﻫﻴﺪ ﻧﻤﻮﺩ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﺎ ﺳﺮﻋﺖ ﺑﻴﺸﺘﺮﻱ feature ﻫﺎ ﺭﺍ ﺑﻪ ﺩﺳﺖ ﻣﺸﺘﺮﻱ ﺧﻮﺍﻫﻴﻢ ﺭﺳﺎﻧﺪ ﻭ ﺩﺭ ﺻﻮﺭﺕ ﺑﺮﻭﺯ ﺧﻄﺎ ﻧﻴﺰ ﺑﺎ ﺑﺨﺶ ﻛﻮﭼﻜﺘﺮﻱ ﺍﺯ ﺳﺎﻣﺎﻧﻪ ﺭﻭﺑﺮﻭ ﺧﻮﺍﻫﻴﻢ ﺑﻮﺩ ﻭ ﺑﺴﺮﻋﺖ ﺑﻴﺸﺘﺮﻱ ﺑﺮ ﻃﺮﻑ ﺧﻮﺍﻫﻴﻢ ﺷﺪ.

3. ﻣﻘﻴﺎﺱ ﭘﺬﻳﺮﻱ

ﺍﺩﺍﻣﻪ ﻣﻲ ﺩﻫﻴﻢ ﺩﺭ ﭘﺮﻭﮊﻩ ﺑﺎﻧﻜﻲ ﺣﺠﻢ ﺗﺮﺍﻛﻨﺶ ﻫﺎ ﺑﺎﻻ ﻣﻲ ﺭﻭﺩ ﻭ ﻣﺎ ﻧﻴﺎﺯﻣﻨﺪ ﺍﺿــﺎﻓﻪ ﻛﺮﺩﻥ ﻣﻨﺎﺑﻊ ﺑﻪ ﭘﺮﻭﮊﻩ ﺑﺮﺍﻱ ﭘﺎﺳــﺦ ﺩﺍﺩﻥ ﺑﻪ ﺍﻓﺰﺍﻳﺶ ﺣﺠﻢ request ﻫﺎ ﻣﻲ ﺑﺎﺷـﻴﻢ. ﻧﺘﻴﺠﻪ ﺍﻱ ﻛﻪ ﺑﻪ ﺁﻥ ﺩﺭ ﻗﺪﻡ ﺍﻭﻝ ﻣﻴﺮﺳـﻴﻢ ﺍﺭﺗﻘﺎء ﺳـﺨﺖ ﺍﻓﺰﺍﺭ ﻣﻲ ﺑﺎﺷـﺪ(ﻳﻚ ﺳـﺮﻭﺭ ﺧﻮﺏ ﺑﺎ config ﺑﺎﻻ) ﺑﻨﺎﺑﺮﺍﻳﻦ ﺳﺨﺖ ﺍﻓﺰﺍﺭ ﺭﺍ ﺍﺭﺗﻘﺎء ﻣﻲ ﺩﻫﻴﻢ ﺑﻪ ﺍﻳﻨﻜﺎﺭ ﻣﻘﺎﻳﺲ ﭘﺬﻳﺮﻱ ﻋﻤﻮﺩﻱ ﻣﻲ ﮔﻮﻳﻨﺪ .ﺧﻮﺏ ﺑﻌﺪ ﺍﺯ ﻣﺪﺗﻲ ﻣ ﺴﻠﻪ ﺣﻞ ﻧ ﺸﺪ ﺑﻪ ﺍﻳﻦ ﻓﻜﺮ ﻣﻲ ﻛﻨﻴﻢ ﻛﻪ ﻣﺜﻼ ﭼﻨﺪ Node ﺍﺯ ﭘﺮﻭﮊﻩ ﺭﺍ ﭘ ﺸﺖ ﻳﻚ Load Balancer ﻗﺮﺍﺭ ﺩﻫﻴﻢ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﺎﺭ ﺭﺍ ﺑﻴﻦ Node ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺗﻘ ﺴﻴﻢ ﻣﻲ ﻧﻤﺎﻳﻴﻢ (ﻣﻘﻴﺎﺱ ﭘﺬﻳﺮﻱ ﺍﻓﻘﻲ ﺗﻘﺴﻴﻢ ﺑﺎﺭ ﺑﻴﻦ ﻧﻮﺩ ﻫﺎﻱ ﺑﻴﺸﺘﺮ) ﻣﺸﻜﻞ ﺑﺮﻃﺮﻑ ﺷﺪ ﺍﻣﺎ ﺑﺎﺭ ﺍﺻﻠﻲ ﻛﻪ ﻣﺎ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻣﻘﺎﻳﺲ ﭘﺬﻳﺮﻱ ﻫﺴﺘﻴﻢ ﻣﺜﻼ ﺩﺭ ﺑﺨﺶ ﺍﻧﻘﺎﻝ ﭘﻮﻝ ﺍﺳﺖ ﺍﻣﺎ ﻣﺎ ﻣﺠﺒﻮﺭ ﺑﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﻫﺴﺘﻴﻢ ﻛﻪ ﻛﻞ ﭘﺮﻭﮊﻩ ﺭﺍ ﺩﺭ ﻳﻚ Node ﺑﺎﻻ ﺑﻴﺎﻭﺭﻳﻢ ﻭ ﻣﻨﺎﺑﻊ ﺯﻳﺎﺩﻱ ﺭﺍ ﺍﺧﺘﺼﺎﺹ ﺩﻫﻴﻢ ﺩﺭ ﺻﻮﺭﺗﻲ ﻛﻪ ﻧﻴﺎﺯ ﻧﻴﺴﺖ.ﺩﺭ ﺻﻮﺭﺗﻲ ﺑﺎ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺑﻪ ﺩﻟﻴﻞ ﻣﺴﺘﻘﻞ ﺑﻮﺩ ﻫﻤﺎﻥ microservice ﺭﺍ scale ﻛﻨﻴﺪ ﻭ ﻫﺰﻳﻨﻪ ﻭ ﻣﻨﺎﺑﻊ ﻭ ﺩﺳﺘﺮﺱ ﻛﻤﺘﺮﻱ ﺭﺍ ﻣﺘﺤﻤﻞ ﺑﺸﻴﻮﻳﺪ .ﻧﻜﺘﻪ ﺑﻌﺪﻱ ﻫﺮ ﺑﺨﺶ ﺍﺯ ﺳﻴﺴﺘﻢ ﺷﺎﻳﺪ ﻧﻴﺎﺯﻣﻨﺪ ﻣﻨﺎﺑﻊ ﺧﺎﺹ ﺧﻮﺩ ﺑﺎﺷﺪ ﻳﻌﻨﻲ ﺑﺨﺸﻲ ﺍﺯ ﺳﻴﺴﺘﻢ ﺑﻪ CPU ﺑﻴﺸﺘﺮ ،ﺑﺨﺸﻲ ﺩﻳﮕﺮ ﺑﻪ RAM ﺩﺭ ﺣﺎﻟﺖ ﻳﻜﭙﺎﺭﭼﻪ ﻣﺎ ﻣﺠﺒﻮﺭ ﻫ ﺴﺘﻴﻢ ﻛﻪ ﻫﻤﻪ ﺍﻳﻦ ﻭﻳﮋﮔﻲ ﻫﺎ ﺭﺍ ﺑﺎﻫﻢ ﺩﺍ ﺷﺘﻪ ﺑﺎ ﺷﻴﻢ ﺩﺭ ﺻﻮﺭﺗﻲ ﻛﻪ ﻣﻌﻤﺎﺭﻱ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻣﻲ ﺗﻮﺍﻧﺪ ﻫﺮ Node ﻣﻲ ﺗﻮﺍﻧﺪ ﻣﻨﺎﺑﻊ ﺧﻮﺩ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ.

4. ﻛﺎﻫﺶ ﻫﺰﻳﻨﻪ ﺧﻄﺎﻫﺎﻱ ﺳﻴﺴﺘﻢ

ﺍﺯ ﻣﺰﺍﻳﺎﻫﺎﻱ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﺭﺍ ﺑﺎ ﺍﻳﻦ ﺗ ﺼﻮﺭ ﻛﻪ ﺩﺭ ﻳﻚ ﭘﺮﻭﮊﻩ Core banking ﻳﻜﭙﺎﺭﭼﻪ ﻣ ﺸﻐﻮﻝ ﺑﻪ ﻛﺎﺭ ﻫ ﺴﺘﻴﻢ ﺩﺭﻳﻜﻲ ﺍﺯ ﺑﺨﺶ ﻫﺎﻱ ﺍﻳﻦ ﭘﺮﻭﮊﻩ ﻣﺎ ﺩﭼﺎﺭ memory leak ﻣﻴ ﺸﻮﻳﻢ ﻭ ﺍﻳﻦ ﺧﻄﺎ ﺑﺎﻋﺚ ﭘﺎﻳﻴﻦ ﺁﻣﺪﻥ ﻛﻞ ﭘﺮﻭﮊﻩ ﻣﻲ ﺷﻮﺩ ﻭ ﭘﻴﺪﺍ ﻛﺮﺩﻥ ﺍﻳﻦ ﺧﻄﺎ ﻣﻲ ﺗﻮﺍﻧﺪ ﺑﻪ ﻛﺎﺭ ﺳﺨﺖ ﻭ ﭘﻴﭽﻴﺪﻩ ﺍﻱ ﺗﺒﺪﻳﻞ ﺷـﻮﺩ ﺍﻳﻦ ﻳﻜﻲ ﺍﺯ ﺗﺠﺮﺑﻪ ﻫﺎﻱ ﻭﺍﻗﻌﻲ ﺑﻨﺪﻩ ﺑﻮﺩ ﻛﻪ ﻧﺸـﺘﻲ ﺧﻴﻠﻲ ﺯﻭﺩ ﺗﺸـﺨﻴﺺ ﺩﺍﺩ ﺷـﺪ ﻭ ﻣﺸـﻜﻠﻲ ﺑﻪ ﻭﺟﻮﺩ ﻧﻴﺎﻭﺭﺩ ﺍﻣﺎ ﺍﻳﻦ ﻣﺸﻜﻞ ﻣﻲ ﺗﻮﺍﻧﺴﺖ ﺑﻪ ﻣﺸﻜﻞ ﺟﺪﻱ ﺗﺒﺪﻳﻞ ﺷﻮﺩ ﻭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﭼﺎﻟﺶ ﺧﻄﺮﻧﺎﻛﻲ ﺑﻜﺸﺎﻧﺪ ﺍﻣﺎ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﻫﺮ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﺑﻪ ﻃﻮﺭ ﻣﺴـﺘﻘﻞ ﻣﻲ ﺑﺎﺷـﺪ ﺩﺭﺻـﻮﺭﺕ ﺑﺮﻭﺯ ﺧﻄﺎ ﺩﺭ ﻫﻤﺎﻥ microservice ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻭ ﺧﻄﺎ ﺩﺭ ﻫﻤﺎﻥ ﺟﺎ ﻭﺩﺭ ﻫﻤﺎﻥ ﺑﺨﺶ ﻣﺘﻮﻗﻒ ﻣﻲ ﺷـﻮﺩ ﻭ ﺗﻤﺎﻡ ﺳﻴ ﺴﺘﻢ ﺭﺍ fail ﻧﺨﻮﺍﻫﺪ ﻧﻤﻮﺩ . ﻣﻦ ﻣﻄﻠﺒﻲ ﺍﺯ ﻛﺘﺎﺏ art of test ﻧﻘﻞ ﻣﻲ ﻛﻨﻢ ﻛﻪ ﻧﻮ ﺷﺘﻪ ﺑﻮﺩ ﺩﺭ ﻛﺪ ﻫﺎﻱ ﺑﺰﺭﮒ ﻭ ﭘﻴﭽﻴﺪﻩ ﺗﻐﻴﻴﺮ ﻛﻮﭼﻚ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺗﺎﺛﻴﺮﻱ ﺩﺭ ﺟﺎﻱ ﺩﻳﮕﺮ ﺍﺯﺳﻴﺴﺘﻢ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻫﺮ ﭼﻘﺪﺭ ﺣﺠﻢ ﻛﺪﻫﺎ ﺑﻴﺸﺘﺮ ﺑﺎﺷﺪ ﺍﻣﻜﺎﻥ ﺍﻳﻨﻜﻪ ﺗﻐﻴﻴﺮ ﺷﻤﺎ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﺁﻣﺪﻥ ﻣﺸﻜﻠﻲ ﺩﻳﮕﺮ ﺩﺭ ﺑﺨﺸﻲ ﺩﻳﮕﺮﻱ ﺍﺯ ﻛﺪ ﺑﺎﺷﺪ ﺑﻴﺸﺘﺮ ﺍﺳﺖ ﺷﺎﻳﺪ ﻳﻌﻨﻲ ﺍﺛﺮ ﭘﺮﻭﺍﻧﻪ ﺍﻱ . ﺩﺭ ﻃﻮﻝ ﺳﺎﺑﻘﻪ ﻛﺎﺭﻱ ﺧﻮﻳﺶ ﻣﻦ ﺑﺎﺭﻫﺎ ﻣﺸﺎﻫﺪﻩ ﻧﻤﻮﺩﻩ ﺍﻡ ﻛﻪ ﺭﻓﻊ ﺑﺎﮒ ﺩﺭ ﺑﺨ ﺸﻲ ﺍﺯ ﻛﺪ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﺁﻣﺪﻥ ﻣ ﺸﻜﻞ ﺩﺭ ﺑﺨﺶ ﺩﻳﮕﺮﻱ ﺍﺯ ﺳﺎﻣﺎﻧﻪ ﺷﺪﻩ ﺍ ﺳﺖ.ﺍﻣﺎ ﺍﺯ ﻣﺰﺍﻳﺎﻳﻲ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﻣ ﺴﺘﻘﻞ ﺑﻮﺩﻥ ﺍﺳـﺖ ﻛﻪ ﺩﺭ ﺻـﻮﺭﺕ ﺑﺮﻭﺯ ﺧﻄﺎ ﺑﻪ ﻃﻮﺭ ﻣﺸـﺨﺺ ﺍﻳﻨﻜﻪ ﺩﺭ ﻛﺠﺎ ﺑﻪ ﺩﻧﺒﺎﻝ ﺁﻥ ﺑﮕﺮﺩﻳﺪ ﻭ ﺗﺎﺛﻴﺮ ﺁﻥ ﺭﺍ ﺩﺭ ﺍﺑﻌﺪﺍﺩ ﻫﻤﺎﻥ ﻣﻴﻜﺮﻭﺳـﺮﻭﻳﺲ ﺧﻮﺩ ﻛﻨﺘﺮﻝ ﻧﻤﺎﻳﻴﺪ ﺍﻟﺒﺘﻪ ﺍﮔﺮ ﺳﺮﻭﻳﺲ ﺩﭼﺎﺭ ﻣﺸﻜﻞ ﺷﻮﺩ ﻣﻤﻜﻦ ﺍﺳﺖ ﺩﭼﺎﺭ cascading failure ﺑﺸﻮﻳﻢ ﻭ ﻛﻞ ﺳﻴﺴﺘﻢ ﺩﭼﺎﺭ ﺍﺧﺘﻼﻝ ﺑﺸﻮﺩ ﺍﻣﺎ ﺑﺮﺍﻱ ﺍﻳﻦ ﺍﺗﻔﺎﻕ ﺍﻟﮕﻮﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻭﺟﻮﺩ ﺩﺍﺭﺩ.

5. ﺗﺠﺮﺑﻪ ﺗﻜﻨﻮﻟﻮﮊﻱ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ

ﻭ ﺁﺧﺮﻳﻦ ﻣﺰﺍﻳﺎﻳﻲ ﻣﻴﻜﺮﻭﺳـﺮﻭﻳﺲ ﺩﺭ ﻫﻤﺎﻥ ﭘﺮﻭﮊﻩ ﺑﺰﺭﮒ ﺑﺎﻧﻜﻲ ﻳﻜﭙﺎﺭﭼﻪ،ﻓﺮﺽ ﻛﻨﻴﺪ ﺭﻭﺯﻫﺎﻱ ﺍﻭﻟﻴﻪ ﺷـﺮﻭﻉ ﻛﺎﺭ ﺍﻳﻦ ﭘﺮﻭﮊﻩ ﺍﺳـﺖ ﺷـﻤﺎ ﺑﺎﻳﺪ stack ﺗﻜﻨﻮﻟﻮﮊﻱ ﺭﺍ ﻣﺸــﺨﺺ ﻛﻨﻴﺪ ﻛﻪ ﺍﻳﻦ ﭘﺮﻭﮊﻩ ﺑﺎ ﭼﻪ ﺗﻜﻨﻮﻟﻮﮊﻱ ﻫﺎﻱ ﻧﻮﺷــﺘﻪ ﺧﻮﺍﻫﺪ ﺣﺎﻻ ﺍﻧﺘﺨﺎﺏ ﺍﻳﻦ stack ﻧﻴﺰ ﻣﻲ ﺗﻮﺍﻧﺪ ﺍﺯ ﺯﺍﻭﻳﻪ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺑﺮﺭﺳﻲ ﻧﻤﻮﺩ (ﺩﺍﻧﺶ ﻧﻴﺮﻭﻫﺎ،ﭘﻴﭽﻴﺪﮔﻲ،ﺳﻴﺎﺳﺖ ﻫﺎﻱ ﺳﺎﺯﻣﺎﻥ ﻭ (.. ﻛﻪ ﺑﻪ ﺁﻥ ﻧﻤﻲ ﭘﺮﺩﺍﺯﻳﻢ ﺍﻣﺎ ﺩﺭ ﻣﺠﻤﻮﻉ ﺑﺮﺍﻱ ﻛﻞ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﺑﺎﻳﺪ ﻳﻚ ﺗﺼﻤﻴﻢ ﺟﺎﻣﻊ ﮔﺮﻓﺖ ﭼﻪ stack ﺗﻜﻨﻮﻟﻮﮊﻱ ﺍﻣﺎ ﺩﺭ ﺯﻣﺎﻧﻲ ﻛﻪ ﺑﺴﻤﺖ ﻣﺎﻛﺮﻭﺳﺮﻭﻳﺲ ﻣﻴﺮﻭﻳﻢ ﺑﻪ ﺩﻟﻴﻞ ﺍﻳﻨﻜﻪ ﻫﺮ ﺑﺨﺶ ﺑﺼﻮﺭﺕ ﻣﺴﺘﻘﻞ ﻋﻤﻞ ﻣﻲ ﻧﻤﺎﻳﻴﺪ ﻣﺎ ﻣﻲ ﺗﻮﺍﻥ ﻫﺮ ﻗﺴﻤﺖ ﺭﺍ ﺑﺎ ﻳﻚ Stack ﻛﺎﻣﻼ ﻣﺘﻔﺎﻭﺕ ﺍﺯ ﺩﻳﮕﺮ ﺍﺟﺰﺍ ﻧﻮﺷﺖ ﺑﻪ ﻫﻤﻴﻦ ﺩﻟﻴﻞ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﺪ ﺩﺭ ﻫﺮ ﺑﺨﺶ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱ ﭘﺮﻭﮊﻩ ﺍﻧﺘﺨﺎﺏ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻦ.ﻛﻪ ﺍﻟﺒﺘﻪ ﻫﻢ ﻣﻲ ﺗﻮﺍﻧﺪ ﺟﺬﺍﺏ ﺑﺎﺷﺪ ﻭ ﻫﻢ ﻣﻲ ﺗﻮﺍﻧﺪ ﺧﻄﺮ ﻧﺎﻙ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﻣﻮﺍﺟﻪ ﺷﺪﻥ ﺑﺎ ﺍﻧﺒﻮﻫﻲ ﺍﺯ ﺗﻜﻨﻮﻟﻮﮊﻱ ﻣﺘﻔﺎﻭﺕ ﻧﻴﺎﺯ ﺑﻪ ﻧﻴﺮﻭﻫﺎ ﺑﺎ ﺗﺨﺼــﺺ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ،ﭘﻴﭽﻴﺪﮔﻲ ﺑﻴﺸــﺘﺮ ﻭ… ﻣﻲ ﺑﺎﺷــﺪ ﺑﻪ ﻧﻈﺮ ﺑﺎﻳﺪ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﻋﻘﻼﻧﻪ ﻋﻤﻞ ﻧﻤﻮﺩ.

ﭼﺎﻟﺶ ﻫﺎی ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ

ﻫﺮ ﺍﻧﺘﺨﺎﺏ ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺧﻮﺩ ﺭﺍ ﺩﺭ ﺑﺮ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ ﺍﻳﻨﻜﻪ ﺗﺼﻤﻴﻢ ﺑﮕﻴﺮﻳﻢ (trade off) ﺑﻪ ﺗﺠﺮﺑﻪ ﻭ ﺩﺍﻧﺶ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﻱ ﻣﺴﻠﻪ ﺷﻤﺎ ﺑﺮ ﻣﻲ ﮔﺮﺩﺩ.ﺑﺎﻳﺪ ﺩﺭ ﻧﻈﺮ ﺩﺍﺷـﺖ ﻛﻪ ﻣﻴﻜﺮﻭﺳـﺮﻭﻳﺲ ﻫﻢ ﺑﺪﻭﻥ ﻧﻘﺎﻁ ﺗﺎﺭﻳﻚ ﻭ ﭘﻴﭽﻴﺪﻥ ﻧﻴﺴـﺖ ﻛﻪ ﺷـﻨﺎﺧﺖ ﺁﻧﻬﺎ ﺑﻪ ﺷـﻤﺎ ﻛﻤﻚ ﻣﻲ ﻛﻨﺪ ﺍﻧﺘﺨﺎﺏ ﺩﺭﺳﺖ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﺴﻠﻪ ﺧﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻓﺮﺍﻣﻮﺵ ﻧﻜﻨﻴﻢ ﻛﻪ ﺍﺑﺰﺍﺭ ﻳﺎ ﻣﻌﻤﺎﺭﻱ ﻫﺎ ﺑﺮﺍﻱ ﺣﻞ ﻫﻤﻪ ﻣﺴﺎﺋﻞ ﻣﻨﺎﺳﺐ ﻧﻤﻲ ﺑﺎﺷﻨﺪ ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﺴﻠﻪ ﺭﺍ ﺑﻪ ﺧﻮﺑﻲ ﺑﺎﻳﺪ ﺷﻨﺎﺧﺖ ﻭ ﺑﻬﺘﺮﻳﻦ ﺭﺍﻩ ﺣﻞ ﻣﻤﻜﻨﻪ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻧﻤﻮﺩ.ﺣﺎﻻ ﺍﺟﺎﺯﻩ ﺩﻫﻴﺪ ﺑﻪ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺑﭙﺮﺩﺍﺯﻳﻢ.

  •  ﭘﻴﺪﺍ ﻛﺮﺩﻥ ﻣﺮﺯ ﺩﺭﺳﺖ ﺑﻴﻦ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ
  •  ﻣﺸﻜﻼﺕ ﺳﻴﺴﺘﻢ ﺗﻮﺯﻳﻊ ﺷﺪﻩ
  •  ﺍﻓﺰﺍﻳﺶ ﭘﻴﭽﻴﺪﮔﻲ ﺩﺭ ﺣﺎﻟﺘﻲ ﻛﻪ ﻣﺤﺼﻮﻝ ﺷﻤﺎ ﻧﻴﺎﺯﻣﻨﺪﺑﻪ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﺩﻳﮕﺮ ﺍﺳﺖ

1. ﭘﻴﺪﺍ ﻛﺮﺩﻥ ﻣﺮﺯ ﺩﺭﺳﺖ ﺑﻴﻦ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ

ﺧﻮﺏ ﺑﺮﮔﺮﺩﻳﻢ ﺑﻪ ﻣﺜﺎﻝ core banking ﻳﻜﭙﺎﺭﭼﻪ ﺍﻱ ﺩﺍ ﺷﺘﻴﻢ ﻳﻜﻲ ﺍﺯ ﺗ ﺼﻤﻴﻤﺎﺕ ﺳﺨﺖ ﺍﻳﻦ ﺍ ﺳﺖ ﻛﻪ ﭼﮕﻮﻧﻪ ﺍﻳﻦ ﺳﻴ ﺴﺘﻢ ﭘﻜﭙﺎﺭﭼﻪ ﺭﺍ ﺑﻪ ﺯﻳﺮ ﻣﺠﻤﻮﻋﻪ ﻫﺎﻱ ﻛﻮﭼﻜﺘﺮﻱ ﺗﻘﺴﻴﻢ ﻣﻲ ﻧﻤﺎﻳﻴﺪ ﺍﻳﻦ ﺗﺼﻤﻴﻢ ،ﺗﺼﻤﻴﻢ ﺑﺴﻴﺎﺭ ﺑﺎ ﺍﻫﻤﻴﺘﻲ ﺍﺳﺖ ﻛﻪ ﺍﮔﺮ ﺩﺭﺳﺖ ﺍﻧﺠﺎﻡ ﻧﺸﻮﺩ ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻢ ﺷﻤﺎ ﭼﻨﺪ ﭼﻨﺪﺍﻥ ﺧﻮﺍﻫﺪ ﺷﺪ ﻫﻤﺎﻥ ﺳﻴﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﻗﺒﻞ ﺑﺴﻴﺎﺭ ﺑﻬﺘﺮ ﺍﺯ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﭼﻨﺪ ﭘﺎﺭﻩ ﺷﺪﻩ ﺍﺳﺖ.ﻧﻜﺘﻪ ﺍﻱ ﻛﻪ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺁﻥ ﺍﺳﺖ ﻛﻪ ﻫﺮ ﺯﻳﺮ ﺳﻴ ﺴﺘﻢ ﻛﺎﻣﻼ ﺩﺍﺭﺍﻱ ﺍﻧ ﺴﺠﺎﻡ ﺑﺎ ﺷﺪ ﺍﻳﻦ ﻣﻮ ﺿﻮﻉ ﺑﻮﺍ ﺳﻄﻪ ﺗﺠﺮﺑﻪ، ﺷﻨﺎﺧﺖ ﻛﺎﻓﻲ ﺩﺍﻣﻴﻦ ﻣ ﺴﺌﻠﻪ ﻧﻴﺎﺯ ﺩﺍﺭﺩ.ﻣﺜﻼ ﺩﺭ ﻣﺜﺎﻝ ﺑﺎﻧﻜﻲ ﻣﺎ ﻧﺒﺎﻳﺪ ﺑﺨ ﺸﻲ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺳﻮﺩ ﺭﻭﻱ ﺩﺭ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﺗ ﺴﻬﻴﻼﺕ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﺷﺪﻩ ﺑﺎ ﺷﺪ ﻫﺮ ﺁﻧﭽﻪ ﻛﻪ ﺑﺎ ﺳﻮﺩ ﻫ ﺴﺖ ﺑﺎﻳﺪ ﺩﺭ ﻣﺎﻛﺮﻭ ﺳﺮﻭﻳﺲ ﺳﻮﺩ ﻣﺘﻤﺮﻛﺰ ﺷﺪﻩ ﺑﺎﺷﺪ ﻳﻜﭙﺎﺭﭼﻲ ﺭﻋﺎﻳﺖ ﺷﺪﻩ ﺑﺎﺷﺪ.ﺍﮔﺮ ﺍﻳﻨﻜﺎﺭ ﺍﺗﻔﺎﻕ ﺑﻪ ﺩﺭﺳﺘﻲ ﺍﻧﺠﺎﻡ ﻧﺸﻮﺩ ﺗﻤﺎﻡ ﻣﺰﺍﻳﺎﻳﻲ ﻣﺎﻛﺮﻭﺳﺮﻭﻳﺲ ﺑﻲ ﺍﺭﺯﺵ ﺧﻮﺍﻫﺪ ﺑﻮﺩ.


2. ﻣﺸﻜﻼﺕ ﺳﻴﺴﺘﻢ ﺗﻮﺯﻳﻊ ﺷﺪﻩ

ﺍ ﺳﺎ ﺳﺎ ﺳﻴ ﺴﺘﻢ ﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺑﻪ ﻧ ﺴﺒﺖ ﺳﻴ ﺴﺘﻢ ﻫﺎﻱ ﺩﻳﮕﺮ ﺑ ﺴﻴﺎﺭ ﭘﻴﭽﻴﺪﻩ ﺗﺮ ﻭ ﺑﺎ ﭼﺎﻟﺶ ﻫﺎﻱ ﺑﻴ ﺸﺘﺮﻱ ﻫﻤﺮﺍﻩ ﻣﻲ ﺑﺎ ﺷﺪ ﻛﻪ ﺍﻳﻦ ﭼﺎﻟﺶ ﻫﺎ ﮔﺎﻫﻲ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺑﻪ ﻗﺪﺭ ﻛﺎﻓﻲ ﺳﺨﺘﻲ ﺍﻳﺠﺎﺩ ﻧﻤﺎﻳﻨﺪ.ﺯﻣﺎﻧﻲ ﻛﻪ ﺷﻤﺎ ﻣﺪﻝ ﺧﻮﺩ ﺭﺍ ﺑﻪ ﺯﻳﺮ ﻣﺪﻝ ﻫﺎﻱ ﻣ ﺴﺘﻘﻞ ﺗﻘ ﺴﻴﻢ ﻣﻲ ﻧﻤﺎﻳﻴﺪ ﻭ ﻫﺮﻳﻚ ﻣﻲ ﺗﻮﺍﻧﺪ ﺩﻳﺘﺎ ﺑﻴﺲ ﻣﺠﺰﺍﻱ ﺧﻮﺩ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺑﻄﻮﺭ ﻣﺜﺎﻝ ﻣﺪﻳﺮﻳﺖ ﻛﺮﺩﻥ transaction ﺧﻮﺩ ﻳﻚ ﭼﺎﻟﺶ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻭ ﺩﺍﺭﺍﻱ ﭘﻴﭽﻴﺪﮔﻲ ﻫﺎﻱ ﺧﺎﺹ ﺧﻮﺩ ﻳﺎ ﻓﺮﺽ ﺩﻳﮕﺮ، ﺷﻤﺎ ﺑﺮﺍﻱ ﻓﺮﺁﻳﻨﺪ ﺷﺎﺭﮊ ﻧﻴﺎﺯ ﺑﻪ ﺳﺮﻭﻳﺲ ﺍﻧﺘﻘﺎﻝ ﭘﻮﻝ ﺩﺍﺭﻳﺪ ﺯﻣﺎﻧﻲ ﻛﻪ ﺩﺭ ﻳﻚ ﺩﺍﻣﻴﻦ ﻧﺒﺎ ﺷﻴﺪ ﻧﻴﺎﺯ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﺍﻧﺘﻘﺎﻝ ﭘﻮﻝ ﺩﺍﺭﻳﺪ ﻛﻪ ﻣﻤﻜﻨﻪ ﺍﺳﺖ ﺑﺎ ﺧﻄﺎ ﻣﻮﺍﺟﻪ ﺷﻮﻳﺪ،ﻛﻨﺪﻱ ﺷﺒﻜﻪ ﺭﺍ ﺗﺠﺮﺑﻪ ﻛﻨﻴﺪ،ﻛﻨﺪﻱ ﺩﺭ ﺳﺮﻭﻳﺲ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻦ ﻭ ﻣﻮﺍﺭﺩ ﺩﻳﮕﺮ ﻛﻪ ﺑﺮﺍﻱ ﻫﺮﻳﻚ ﺑﺎﻳﺪ ﺁﻣﺎﺩﮔﻲ ﻻﺯﻡ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻦ ﻛﻪ ﺍﻟﺒﺘﻪ ﺩﺭﺳﻴﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﺩﭼﺎﺭ ﺍﻳﻦ ﻣﺸﻜﻼﺕ ﻧﺨﻮﺍﻫﻴﺪ ﺑﻮﺩ.

3. ﺍﻓﺰﺍﻳﺶ ﭘﻴﭽﻴﺪﮔﻲ ﺩﺭ ﺣﺎﻟﺘﻲ ﻛﻪ ﻣﺤﺼﻮﻝ ﺷﻤﺎ ﻧﻴﺎﺯﻣﻨﺪﺑﻪ ﺳﺮﻭﻳﺲ ﺩﻳﮕﺮ ﺍﺳﺖ

ﻧﺨ ﺴﻪ ﮔﺬﺍﺭﻱ ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ﻣﻤﻜﻦ ﺍ ﺳﺖ ﻫﻤﺮﺍﻩ ﺑﺎ ﭘﻴﭽﻴﺪﮔﻴﻬﺎﻱ ﻧﻴﺰ ﺑﺎ ﺷﺪ ﻓﺮﺽ ﻛﻨﻴﺪ ﻛﻪ ﻣﻴﻜﺮﻭ ﺳﺮﻭﻳﺲ ﺷﻤﺎ ﻣﺜﻼ ﺗ ﺴﻮﻳﻪ ﻣﻤﻜﻦ ﺍ ﺳﺖ ﻛﻪ ﻧﻴﺎﺯﻣﻨﺪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﺍﺯ ﭼﻨﺪ ﻣﻴﻜﺮﻭﺳﺮﻭﻳﺲ ﺩﻳﮕﺮ ﺑﺎﺷﺪ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺗﺴﻮﻳﻪ ﺑﺮﺍﻱ ﻛﺎﻣﻞ ﺷﺪﻥ features ﺧﻮﺩ ﺑﻪ ﺳﺮﻭﻳﺲ ﻫﺎﻱ ﺧﺎﺭﺝ ﺍﺯ ﺩﺍﻣﻨﻪ ﺧﻮﺩ ﻧﻴﺎﺯﻣﻨﺪ ﺍﺳـﺖ ﺩﺭ ﺍﻳﻦ ﺣﺎﻟﺖ ﺑﺮﺍﻱ ﻧﺴـﺨﻪ ﮔﺬﺍﺭﻱ ﻧﻴﺎﺯﻣﻨﺪ ﻫﻤﺎﻫﻨﮕﻲ ﺑﺎ ﺗﻴﻢ ﺩﻳﮕﺮ ﻣﻲ ﺑﺎﺷـﺪ. ﻭ ﻫﻤﭽﻨﻴﻦ ﺩﺭ ﻛﺘﺎﺏ Release It ﺁﻣﺪﻩ ﺍﺳﺖ ﻛﻪ ﻫﺮ ﺯﻣﺎﻥ ﻛﻪ ﺷﻤﺎ ﻣﺠﺒﻮﺭ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﻣﻲ ﺷﻮﻳﺪ ﻋﻤﻼ ﻳﻚ ﻧﻘﻄﻪ ﺑﺮﺍﻱ fail ﺷﺪﻥ ﺳﻴﺴﺘﻢ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻩ ﺍﻳﺪ ﺑﻪ ﺩﻟﻴﻞ ﻭﺍﺑ ﺴﺘﮕﻲ ﻛﻪ ﺑﻪ ﺳﻴ ﺴﺘﻢ ﻫﺎﻱ ﺩﻳﮕﺮ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲ ﺁﻳﺪ ﻭ ﺗﻬﺪﻳﺪ ﻫﺎﻱ ﻭ ﻫﺰﻳﻨﻪ ﻫﺎﻱ ﻛﻪ ﺩﺭ ﺭﺍ ﺳﺘﺎﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲ ﺩﻳﮕﺮ ﺑﺎﻳﺪ ﻣﺘﺤﻤﻞ ﺷﺪﻭ ﺑﺤﺚ ﻫﺎﻱ ﺍﺯ ﺟﻤﻠﻪ ﺍﻣﻨﻴﺖ .

ﭘﺎﻳﺎﻥ

ﺩﻭﺳﺘﺎﻥ ﺧﻮﺑﻢ ﺍﻣﻴﺪﻭﺍﺭﻡ ﻟﺬﺕ ﺑﺮﺩﻩ ﺑﺎﺷﻴﻦ ﻭ ﺧﻮﺷﺤﺎﻟﻢ ﻣﻴﺸﻢ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﻣﻮﺭﺩ ﺑﺎ ﻫﻢ ﺩﺍﻧﺸﻤﻮﻧﻈﻂ ﺭﻭ ﺑﻪ ﺍﺷﺘﺮﺍﻙ ﺑﮕﺬﺍﺭﻳﺪ.

نویسنده: علی لطفی

https://Github.com/LotfiAli

LotfiAliDev@gmail.com

: ﻣﻨﺒﻊ

Microservices Patterns WITH EXAMPLES IN JAVA C HRIS R ICHARDSON

https://martinfowler.com/bliki/CircuitBreaker.html

دسته بندی شده در:

مقاله ها

برچسب ها:

,