The primary goal of this diploma thesis is to migrate project InfiSpector to anewer version of Angular framework. In the begining is described project InfiSpec-tor itself followed by an analysis of Angular framework, Druid database, streamingplatform Kafka and Test Driven Development process. Metodology chapter presentsan outline of theoretical plan for a practical part. The practical part describes theprocess of project InfiSpector migration and presents solutions for obstacles met onthe way. The conclusion summarizes thesis results.

隨著電子商務的蓬勃發展，不論是使用者或是服務提供者，對於系統的可靠度(reliability)，越來越為重視，從『能提供服務就好』，到要能提供『不間斷的服務』。這中間的轉變，推動了目前許多系統架構或產品運用在電子商務的領域。小從磁碟陣列(RAID)、資料庫鏡像(Database Mirror)、叢集(Cluster)架構，異地備援(Disaster Recovery Site)，大到企業永續運作計畫(Business Continuity Planning-BCP)的一環，都在尋求一個高可靠度的電子交易系統。 所謂高可靠度的系統，必須能夠在相對長的時間週期內，系統可以持續運作而不中斷，這個概念，同時也意味著系統異常時的恢復能力，以及容錯的機制。換句話說，就是當系統面臨異常或是災害發生時，如何能在最短的時間內恢復系統的正常運作，繼續提供使用者相同的服務。因此提高系統的可靠度，對使用者的具體意義而言，即是提高其服務的可用度(availability)。 本論文的研究，即運用Apache下自由軟體Zookeeper所提供的協調服務，設計一套透過傳播監控(propagation monitor)來達到容錯機制的對稱式多主機架構，使得系統即使在面對異常狀況發生時，仍能迅速恢復系統應有的功能，提供使用者不間斷的服務。並且利用免費的資料庫管理軟體-MariaDB來儲存及操作資料，以低廉的成本，建置具高可靠度的電子交易系統。 / Due to the blooming development of electronic commerce (E-Commerce) , both users and service providers put more and more emphasis on system reliability. Thus uninterrupted service has become the basic requirement of E-Commerce systems, which now have all adopted some highly avaialable system architectures and advanced products such as Redundant Array of Independent Disks (RAID), Database Mirror, Cluster architecture, Disaster Recovery Site(DR Site). Many E-Commerce vendors also prepare Business Continuity Planning(BCP) for a highly reliable electronic trading system. The so-called high reliability systems must continue to operate without interruption in a relatively long period of time, and this concept also means the requirements of abnormal system resilience and the mechanism of fault tolerance. In other words, when the system is confronted with abnormal situations or disaster occurs, it is critical about how to restore the normal functioning of the system to continue to provide users with the same level of services in the shortest possible time, thereby increasing the reliability of the system in terms of the user's specific meaning, that is, to improve its service availability. This thesis applies the coordination service provided by Zookeeper to develop a propagation monitor mechanism and a symmetrical multi-host fault-tolerant system architecture, making the system work even in the face of an abnormal situation. Indeed, the system should be able to quickly restore its functions, providing users uninterrupted service. Besides, we use the free database management software-MariaDB to store and operate the system data. Therefore, we are able to build a low-cost yet highly available electronic trading system.

Att flera datorer används för att gemensamt lösa problem är inte någonting nytt. Det finns många distribuerade system i bruk och många olika lösningar för hur dessa ska kommunicera med varandra. Vissa använder sig av meddelande-orienterade lager för kommunikation vilket det finns väldigt många implementationer av. RabbitMQ är ett exempel där att kommunikation går genom en (eller ett kluster av) central nod och kommunicerar med hjälp av protokollet Advanced Message Queue Protocol, AMQP. I en helt annan kategori finns ZeroMQ som inte definierar någon central nod för all kommunikation att passera utan peer to peer är istället möjlig vilket innebär snabbare responstider men försvårar hur olika klienter hittar till varandra. Det bloggindexerande företaget Twingly kör idag med ett distribuerat system som använder flera olika kösystem för att koordinera ut arbete till de olika datorerna. De vill kolla närmare på hur de kan bygga sitt system med hjälp av meddelande-orienterade lager. Resultatet av arbetet är att RabbitMQ innebär mindre komponenter att hålla reda på vilket innebär att koden blir mindre komplex. Det som kommer gratis med att använda RabbitMQ är just att klienterna inte behöver känna till varandra utan endast behöver känna till RabbitMQ-servern. Nackdelen är att RabbitMQ-servern kommer bli en flaskhals för systemet. ZeroMQ är däremot friare att implementera den funktionalitet man själv behöver vilket är till fördel i de fall tid och pengar finns för att skapa ett eget system byggt ovanpå ZeroMQ. För Twingly som vill ha ett system inom en snar framtid är RabbitMQ ett bättre val av dessa två alternativ.