ViennaNET: ຊຸດຂອງຫ້ອງສະຫມຸດສໍາລັບ backend ໄດ້. ພາກທີ 2

ຊຸມຊົນນັກພັດທະນາ Raiffeisenbank .NET ສືບຕໍ່ທົບທວນເນື້ອໃນຂອງ ViennaNET ໂດຍຫຍໍ້. ກ່ຽວກັບວິທີການແລະເປັນຫຍັງພວກເຮົາມານີ້, ທ່ານສາມາດອ່ານພາກທໍາອິດ.

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະຜ່ານຫ້ອງສະຫມຸດທີ່ຍັງບໍ່ໄດ້ຮັບການພິຈາລະນາສໍາລັບການເຮັດວຽກກັບທຸລະກໍາແຈກຢາຍ, ແຖວແລະຖານຂໍ້ມູນ, ເຊິ່ງສາມາດພົບໄດ້ຢູ່ໃນບ່ອນເກັບມ້ຽນ GitHub ຂອງພວກເຮົາ (ແຫຼ່ງຂໍ້ມູນແມ່ນຢູ່ທີ່ນີ້), ກ ແພັກເກດ Nuget ຢູ່ທີ່ນີ້.

ViennaNET.Sagas

ເມື່ອໂຄງການປ່ຽນໄປໃຊ້ DDD ແລະສະຖາປັດຕະຍະກໍາຈຸລະພາກ, ຫຼັງຈາກນັ້ນໃນເວລາທີ່ເຫດຜົນທາງທຸລະກິດຖືກແຈກຢາຍໃນທົ່ວການບໍລິການທີ່ແຕກຕ່າງກັນ, ບັນຫາທີ່ເກີດຂື້ນກັບຄວາມຕ້ອງການທີ່ຈະປະຕິບັດກົນໄກການເຮັດທຸລະກໍາທີ່ແຈກຢາຍ, ເພາະວ່າຫຼາຍໆສະຖານະການມັກຈະສົ່ງຜົນກະທົບຕໍ່ຫລາຍໂດເມນໃນເວລາດຽວກັນ. ທ່ານສາມາດຮູ້ຈັກກັບກົນໄກດັ່ງກ່າວໃນລາຍລະອຽດເພີ່ມເຕີມ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນປຶ້ມ "ຮູບແບບການບໍລິການຈຸລະພາກ", Chris Richardson.

ໃນໂຄງການຂອງພວກເຮົາ, ພວກເຮົາໄດ້ປະຕິບັດກົນໄກທີ່ງ່າຍດາຍແຕ່ມີປະໂຫຍດ: saga, ຫຼືແທນທີ່ຈະເປັນ saga ອີງໃສ່ orchestration. ໂດຍເນື້ອແທ້ແລ້ວຂອງມັນແມ່ນດັ່ງນີ້: ມີສະຖານະການທຸລະກິດສະເພາະໃດຫນຶ່ງທີ່ມັນຈໍາເປັນຕ້ອງດໍາເນີນການຕາມລໍາດັບໃນການບໍລິການທີ່ແຕກຕ່າງກັນ, ແລະຖ້າບັນຫາໃດໆເກີດຂື້ນໃນຂັ້ນຕອນໃດກໍ່ຕາມ, ມັນຈໍາເປັນຕ້ອງໂທຫາຂັ້ນຕອນການກັບຄືນສໍາລັບຂັ້ນຕອນທີ່ຜ່ານມາທັງຫມົດ, ບ່ອນທີ່ມັນຢູ່. ສະຫນອງໃຫ້. ດັ່ງນັ້ນ, ໃນຕອນທ້າຍຂອງ saga, ໂດຍບໍ່ຄໍານຶງເຖິງຜົນສໍາເລັດ, ພວກເຮົາໄດ້ຮັບຂໍ້ມູນທີ່ສອດຄ່ອງໃນທຸກໂດເມນ.

ການປະຕິບັດຂອງພວກເຮົາແມ່ນຍັງເຮັດຢູ່ໃນຮູບແບບພື້ນຖານຂອງມັນ ແລະບໍ່ໄດ້ຕິດພັນກັບການໃຊ້ວິທີການພົວພັນໃດໆກັບການບໍລິການອື່ນໆ. ມັນບໍ່ຍາກທີ່ຈະໃຊ້: ພຽງແຕ່ເຮັດໃຫ້ລູກຫລານຂອງຊັ້ນຮຽນທີ່ບໍ່ມີຕົວຕົນ SagaBase<T>, ບ່ອນທີ່ T ແມ່ນຫ້ອງຮຽນສະພາບການຂອງທ່ານທີ່ທ່ານສາມາດເກັບຮັກສາຂໍ້ມູນເບື້ອງຕົ້ນທີ່ຈໍາເປັນສໍາລັບ saga ເຮັດວຽກ, ເຊັ່ນດຽວກັນກັບບາງຜົນໄດ້ຮັບລະດັບປານກາງ. ສະພາບການຕົວຢ່າງຈະຖືກສົ່ງຜ່ານໄປທຸກຂັ້ນຕອນໃນລະຫວ່າງການປະຕິບັດ. Saga ຕົວຂອງມັນເອງເປັນຫ້ອງຮຽນທີ່ບໍ່ມີລັດ, ດັ່ງນັ້ນຕົວຢ່າງສາມາດຖືກຈັດໃສ່ໃນ DI ເປັນ Singleton ເພື່ອໃຫ້ໄດ້ຮັບການເພິ່ງພາອາໄສທີ່ຈໍາເປັນ.

ຕົວຢ່າງໂຄສະນາ:

public class ExampleSaga : SagaBase<ExampleContext>
{
  public ExampleSaga()
  {
    Step("Step 1")
      .WithAction(c => ...)
      .WithCompensation(c => ...);
	
    AsyncStep("Step 2")
      .WithAction(async c => ...);
  }
}

ຕົວຢ່າງການໂທ:

var saga = new ExampleSaga();
var context = new ExampleContext();
await saga.Execute(context);

ຕົວຢ່າງອັນເຕັມທີ່ຂອງການປະຕິບັດທີ່ແຕກຕ່າງກັນສາມາດເບິ່ງໄດ້ ທີ່ນີ້ ແລະໃນສະພາແຫ່ງ ການທົດສອບ.

ViennaNET.Orm.*

ຊຸດຂອງຫ້ອງສະຫມຸດສໍາລັບການເຮັດວຽກກັບຖານຂໍ້ມູນຕ່າງໆຜ່ານ Nhibernate. ພວກເຮົາໃຊ້ວິທີການ DB-First ໂດຍໃຊ້ Liquibase, ດັ່ງນັ້ນພຽງແຕ່ມີຫນ້າທີ່ເຮັດວຽກກັບຂໍ້ມູນໃນຖານຂໍ້ມູນທີ່ກຽມພ້ອມ.

ViennaNET.Orm.Seedwork и ViennaNET.Orm - ສະພາແຫ່ງຕົ້ນຕໍທີ່ປະກອບດ້ວຍການໂຕ້ຕອບພື້ນຖານແລະການຈັດຕັ້ງປະຕິບັດຂອງພວກເຂົາ, ຕາມລໍາດັບ. ໃຫ້ເບິ່ງເນື້ອໃນຂອງເຂົາເຈົ້າໃນລາຍລະອຽດເພີ່ມເຕີມ.

ການໂຕ້ຕອບ IEntityFactoryService ແລະ​ການ​ປະ​ຕິ​ບັດ​ຂອງ​ຕົນ​ EntityFactoryService ເປັນຈຸດເລີ່ມຕົ້ນຕົ້ນຕໍສໍາລັບການເຮັດວຽກກັບຖານຂໍ້ມູນ, ນັບຕັ້ງແຕ່ຫນ່ວຍງານຂອງການເຮັດວຽກ, repositories ສໍາລັບການເຮັດວຽກກັບຫນ່ວຍງານສະເພາະ, ເຊັ່ນດຽວກັນກັບຜູ້ປະຕິບັດຄໍາສັ່ງແລະການສອບຖາມ SQL ໂດຍກົງແມ່ນສ້າງຢູ່ທີ່ນີ້. ບາງຄັ້ງມັນສະດວກທີ່ຈະຈໍາກັດຄວາມສາມາດຂອງຫ້ອງຮຽນສໍາລັບການເຮັດວຽກກັບຖານຂໍ້ມູນ, ຕົວຢ່າງ, ສະຫນອງຄວາມສາມາດໃນການອ່ານຂໍ້ມູນເທົ່ານັ້ນ. ສໍາລັບກໍລະນີດັ່ງກ່າວ IEntityFactoryService ມີບັນພະບຸລຸດ - ການໂຕ້ຕອບ IEntityRepositoryFactory, ເຊິ່ງພຽງແຕ່ປະກາດວິທີການສ້າງ repositories.

ເພື່ອເຂົ້າເຖິງຖານຂໍ້ມູນໂດຍກົງ, ກົນໄກຜູ້ໃຫ້ບໍລິການຖືກນໍາໃຊ້. ແຕ່ລະ DBMS ທີ່ພວກເຮົາໃຊ້ຢູ່ໃນທີມງານຂອງພວກເຮົາມີການປະຕິບັດຂອງຕົນເອງ: ViennaNET.Orm.MSSQL, ViennaNET.Orm.Oracle, ViennaNET.Orm.SQLite, ViennaNET.Orm.PostgreSql.

ໃນເວລາດຽວກັນ, ຜູ້ໃຫ້ບໍລິການຫຼາຍໆຄົນສາມາດລົງທະບຽນຢູ່ໃນຄໍາຮ້ອງສະຫມັກຫນຶ່ງໃນເວລາດຽວກັນ, ເຊິ່ງອະນຸຍາດໃຫ້, ສໍາລັບຕົວຢ່າງ, ພາຍໃນກອບຂອງການບໍລິການຫນຶ່ງ, ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍໃດໆສໍາລັບການດັດແປງໂຄງສ້າງພື້ນຖານ, ເພື່ອປະຕິບັດການເຄື່ອນຍ້າຍຂັ້ນຕອນໂດຍຂັ້ນຕອນຈາກ. ຫນຶ່ງ DBMS ກັບອີກ. ກົນໄກສໍາລັບການເລືອກການເຊື່ອມຕໍ່ທີ່ຕ້ອງການແລະດັ່ງນັ້ນ, ຜູ້ໃຫ້ບໍລິການສໍາລັບຊັ້ນ entity ສະເພາະ (ສໍາລັບແຜນທີ່ກັບຕາຕະລາງຖານຂໍ້ມູນແມ່ນຂຽນ) ແມ່ນປະຕິບັດໂດຍຜ່ານການລົງທະບຽນ entity ໃນ BoundedContext class (ມີວິທີການລົງທະບຽນຫນ່ວຍງານໂດເມນ) ຫຼືຜູ້ສືບທອດຂອງມັນ. ApplicationContext (ປະກອບດ້ວຍວິທີການລົງທະບຽນຫນ່ວຍງານຄໍາຮ້ອງສະຫມັກ, ການຮ້ອງຂໍໂດຍກົງແລະຄໍາສັ່ງ), ບ່ອນທີ່ຕົວລະບຸການເຊື່ອມຕໍ່ຈາກການຕັ້ງຄ່າຖືກຍອມຮັບເປັນການໂຕ້ຖຽງ:

"db": [
  {
    "nick": "mssql_connection",
    "dbServerType": "MSSQL",
    "ConnectionString": "...",
    "useCallContext": true
  },
  {
    "nick": "oracle_connection",
    "dbServerType": "Oracle",
    "ConnectionString": "..."
  }
],

ຕົວ​ຢ່າງ ApplicationContext:

internal sealed class DbContext : ApplicationContext
{
  public DbContext()
  {
    AddEntity<SomeEntity>("mssql_connection");
    AddEntity<MigratedSomeEntity>("oracle_connection");
    AddEntity<AnotherEntity>("oracle_connection");
  }
}

ຖ້າ ID ການ​ເຊື່ອມ​ຕໍ່​ບໍ່​ໄດ້​ລະ​ບຸ​ໄວ້​, ຫຼັງ​ຈາກ​ນັ້ນ​ການ​ເຊື່ອມ​ຕໍ່​ທີ່​ມີ​ຊື່ "ຄ່າ​ເລີ່ມ​ຕົ້ນ​" ຈະ​ຖືກ​ນໍາ​ໃຊ້​.

ການສ້າງແຜນທີ່ໂດຍກົງຂອງຫນ່ວຍງານກັບຕາຕະລາງຖານຂໍ້ມູນແມ່ນປະຕິບັດໂດຍໃຊ້ເຄື່ອງມື NHibernate ມາດຕະຖານ. ທ່ານສາມາດນໍາໃຊ້ຄໍາອະທິບາຍທັງຜ່ານໄຟລ໌ xml ແລະຜ່ານຫ້ອງຮຽນ. ສໍາລັບການຂຽນທີ່ສະດວກຂອງ stub repositories ໃນ Unit tests, ມີຫ້ອງສະຫມຸດ ViennaNET.TestUtils.Orm.

ຕົວຢ່າງອັນເຕັມທີ່ຂອງການໃຊ້ ViennaNET.Orm.* ສາມາດພົບໄດ້ ທີ່ນີ້.

ViennaNET.ການສົ່ງຂໍ້ຄວາມ.*

ຊຸດຂອງຫ້ອງສະຫມຸດສໍາລັບການເຮັດວຽກກັບຄິວ.

ເພື່ອເຮັດວຽກກັບຄິວ, ວິທີການດຽວກັນໄດ້ຖືກເລືອກເຊັ່ນດຽວກັນກັບ DBMSs ຕ່າງໆ, ຄື, ວິທີການທີ່ເປັນເອກະພາບສູງສຸດທີ່ເປັນໄປໄດ້ໃນການເຮັດວຽກກັບຫ້ອງສະຫມຸດ, ບໍ່ວ່າຈະເປັນຜູ້ຈັດການຄິວທີ່ໃຊ້. ຫໍສະໝຸດ ViennaNET.Messaging ແມ່ນຄວາມຮັບຜິດຊອບຢ່າງແນ່ນອນສໍາລັບການລວມນີ້, ແລະ ViennaNET.Messaging.MQSeriesQueue, ViennaNET.Messaging.RabbitMQQueue и ViennaNET.Messaging.KafkaQueue ມີການປະຕິບັດຕົວດັດແປງສໍາລັບ IBM MQ, RabbitMQ ແລະ Kafka, ຕາມລໍາດັບ.

ເມື່ອເຮັດວຽກກັບຄິວ, ມີສອງຂະບວນການ: ຮັບຂໍ້ຄວາມແລະສົ່ງມັນ.

ພິຈາລະນາຮັບ. ມີ 2 ທາງເລືອກທີ່ນີ້: ສໍາລັບການຟັງຢ່າງຕໍ່ເນື່ອງແລະສໍາລັບການໄດ້ຮັບຂໍ້ຄວາມດຽວ. ເພື່ອຟັງແຖວຢ່າງຕໍ່ເນື່ອງ, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງອະທິບາຍເຖິງຊັ້ນປະມວນຜົນທີ່ສືບທອດມາຈາກ IMessageProcessor, ເຊິ່ງຈະຮັບຜິດຊອບສໍາລັບການປະມວນຜົນຂໍ້ຄວາມທີ່ເຂົ້າມາ. ຕໍ່ໄປ, ມັນຕ້ອງໄດ້ຮັບການ "ເຊື່ອມຕໍ່" ກັບແຖວສະເພາະ; ນີ້ແມ່ນເຮັດໄດ້ໂດຍຜ່ານການລົງທະບຽນໃນ IQueueReactorFactory ຊີ້ບອກຕົວລະບຸແຖວຈາກການຕັ້ງຄ່າ:

"messaging": {
    "ApplicationName": "MyApplication"
},
"rabbitmq": {
    "queues": [
      {
        "id": "myQueue",
        "queuename": "lalala",
        ...
      }
    ]
},

ຕົວຢ່າງຂອງການເລີ່ມຕົ້ນຟັງ:

_queueReactorFactory.Register<MyMessageProcessor>("myQueue");
var queueReactor = queueReactorFactory.CreateQueueReactor("myQueue");
queueReactor.StartProcessing();

ຫຼັງຈາກນັ້ນ, ເມື່ອການບໍລິການເລີ່ມຕົ້ນແລະວິທີການຖືກເອີ້ນເພື່ອເລີ່ມຕົ້ນການຟັງ, ຂໍ້ຄວາມທັງຫມົດຈາກແຖວທີ່ກໍານົດໄວ້ຈະໄປຫາໂປເຊດເຊີທີ່ສອດຄ້ອງກັນ.

ເພື່ອຮັບຂໍ້ຄວາມດຽວໃນການໂຕ້ຕອບຂອງໂຮງງານ IMessagingComponentFactory ມີ​ວິ​ທີ​ການ​ CreateMessageReceiverເຊິ່ງຈະສ້າງຜູ້ຮັບທີ່ລໍຖ້າຂໍ້ຄວາມຈາກແຖວທີ່ລະບຸໄວ້ກັບມັນ:

using (var receiver = _messagingComponentFactory.CreateMessageReceiver<TestMessage>("myQueue"))
{
    var message = receiver.Receive();
}

ເພື່ອສົ່ງຂໍ້ຄວາມ ທ່ານຈໍາເປັນຕ້ອງໃຊ້ດຽວກັນ IMessagingComponentFactory ແລະ​ສ້າງ​ຜູ້​ສົ່ງ​ຂໍ້​ຄວາມ​:

using (var sender = _messagingComponentFactory.CreateMessageSender<MyMessage>("myQueue"))
{
    sender.SendMessage(new MyMessage { Value = ...});
}

ມີສາມທາງເລືອກທີ່ພ້ອມທີ່ຈະເຮັດສໍາລັບການ serializing ແລະ deserializing ຂໍ້ຄວາມ: ພຽງແຕ່ຂໍ້ຄວາມ, XML ແລະ JSON, ແຕ່ຖ້າຫາກວ່າມີຄວາມຈໍາເປັນ, ທ່ານສາມາດເຮັດໃຫ້ການໂຕ້ຕອບຂອງທ່ານເອງໄດ້ຢ່າງງ່າຍດາຍ. IMessageSerializer и IMessageDeserializer.

ພວກເຮົາໄດ້ພະຍາຍາມຮັກສາຄວາມສາມາດພິເສດຂອງແຕ່ລະຜູ້ຈັດການແຖວ, e.g. ViennaNET.Messaging.MQSeriesQueue ອະນຸຍາດໃຫ້ທ່ານສົ່ງຂໍ້ຄວາມບໍ່ພຽງແຕ່, ແຕ່ຍັງຂໍ້ຄວາມ byte, ແລະ ViennaNET.Messaging.RabbitMQQueue ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ເສັ້ນ​ທາງ​ແລະ​ການ​ຕໍ່​ຄິວ​ບິນ​. wrapper ອະແດບເຕີຂອງພວກເຮົາສໍາລັບ RabbitMQ ຍັງປະຕິບັດບາງລັກສະນະຂອງ RPC: ພວກເຮົາສົ່ງຂໍ້ຄວາມແລະລໍຖ້າການຕອບສະຫນອງຈາກແຖວຊົ່ວຄາວພິເສດ, ເຊິ່ງຖືກສ້າງຂື້ນພຽງແຕ່ສໍາລັບຂໍ້ຄວາມຕອບສະຫນອງຫນຶ່ງເທົ່ານັ້ນ.

ທີ່ນີ້ ຕົວຢ່າງຂອງການນໍາໃຊ້ແຖວທີ່ມີ nuances ການເຊື່ອມຕໍ່ພື້ນຖານ.

ViennaNET.CallContext

ພວກເຮົາໃຊ້ຄິວບໍ່ພຽງແຕ່ສໍາລັບການເຊື່ອມໂຍງລະຫວ່າງລະບົບທີ່ແຕກຕ່າງກັນ, ແຕ່ຍັງສໍາລັບການສື່ສານລະຫວ່າງ microservices ຂອງຄໍາຮ້ອງສະຫມັກດຽວກັນ, ສໍາລັບຕົວຢ່າງ, ພາຍໃນ saga. ອັນນີ້ເຮັດໃຫ້ຄວາມຕ້ອງການທີ່ຈະສົ່ງພ້ອມກັບຂໍ້ຄວາມຂໍ້ມູນຊ່ວຍເຊັ່ນການເຂົ້າສູ່ລະບົບຂອງຜູ້ໃຊ້, ຕົວກໍານົດການຮ້ອງຂໍສໍາລັບການເຂົ້າສູ່ລະບົບໃນຕອນທ້າຍ, ທີ່ຢູ່ IP ແຫຼ່ງແລະຂໍ້ມູນການອະນຸຍາດ. ເພື່ອປະຕິບັດການສົ່ງຕໍ່ຂໍ້ມູນນີ້, ພວກເຮົາໄດ້ພັດທະນາຫ້ອງສະຫມຸດ ViennaNET.CallContext, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດເກັບຂໍ້ມູນຈາກການຮ້ອງຂໍທີ່ເຂົ້າມາໃນການບໍລິການ. ໃນກໍລະນີນີ້, ວິທີການຮ້ອງຂໍໄດ້ຖືກດໍາເນີນ, ຜ່ານແຖວຫຼືຜ່ານ Http, ບໍ່ສໍາຄັນ. ຫຼັງຈາກນັ້ນ, ກ່ອນທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍຫຼືຂໍ້ຄວາມອອກ, ຂໍ້ມູນຖືກເອົາມາຈາກສະພາບການແລະວາງໄວ້ໃນຫົວ. ດັ່ງນັ້ນ, ການບໍລິການຕໍ່ໄປໄດ້ຮັບຂໍ້ມູນຊ່ວຍແລະຄຸ້ມຄອງມັນໃນທາງດຽວກັນ.

ຂໍ​ຂອບ​ໃຈ​ທ່ານ​ສໍາ​ລັບ​ຄວາມ​ສົນ​ໃຈ​ຂອງ​ທ່ານ​, ພວກ​ເຮົາ​ຫວັງ​ວ່າ​ທ່ານ​ຈະ​ມີ​ຄໍາ​ເຫັນ​ແລະ​ດຶງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com