<p class="shortdesc">This article describes the architecture of MQ.</p> <section class="section" id="Architecture__section_bqv_lng_2mb"><h2 class="doc-tairway">Application Architecture</h2> <div class="p"> <img class="image" id="Architecture__image_y4m_tng_2mb" src="https://obs-cn-shanghai.yun.pingan.com/pcp-portal/20202209170658-16be9bda9798.png"> </div> </section> <section class="section" id="Architecture__section_cnx_tng_2mb"><h2 class="doc-tairway">Deployment Architecture</h2> <div class="p"> <img class="image" id="Architecture__image_l4z_c4g_2mb" src="https://obs-cn-shanghai.yun.pingan.com/pcp-portal/20202209170658-127cc46e9a93.png" width="830"> </div> <p class="p"><strong class="ph b">MQ management platform</strong>—MQ management platform is a standard J2EE application, adopts Tomcat deployment, and the database uses RDS PostgreSQL.</p> <p class="p"><strong class="ph b">Standard message middleware</strong>—The number of NameServer and Broker nodes can be deployed on demand. Broker cluster adopts the master-slave mode, and at least two copies of the messages are stored. We recommend that different nodes be deployed across the AZs, and within the same associated group.</p> <p class="p"><strong class="ph b">Standard message middleware (disaster recovery)</strong>—The disaster recovery environment and standard environment deployment architecture are the same. When standard environmental services are unavailable, the disaster recovery environment needs to be switched to provide lossy services.</p> </section>