Enterprise Application Common Architecture diagram

In the evening, the application of the architecture of the previous research to comb the next, organized an architectural plan, posted here to back up

Here are a few key points for a personal understanding of the architecture:

1. System security

This is the first consideration, taking this picture as an example, the network is divided into 3 zones:

A) The DMZ can be accessed either directly from the public network or with the app core, but not directly to the DB core (typically where the reverse proxy Web server is placed)

b) The app core can interoperate with the DMZ, DB core, but not directly from the public network (typically place application servers, middleware servers, etc.)

c) DB Core zone is only interoperable with app core (typically the core database is placed here)

2, try to eliminate the single point of failure

, in addition to the "Hardware load Balancing" node, other nodes can be deployed as a cluster (db is a bit special, traditional RDBMS to achieve distributed/clustered or difficult, depending on the specific database products, not all databases can easily do sharding), JBoss itself can be implemented through the domain mode +mod_cluster cluster, Redis through Master/slave can be implemented in Sentinel mode ha, IBM MQ itself support cluster, FTP server with the underlying storage array can also do ha , Nginx static resource server self-needless to say

3. Cost

As far as possible to use open source mature products, JBoss, Redis, Nginx, Apache, MySQL, Rabbit MQ is a good choice. Hardware load balancing usually cost is not low, but the effect is obvious, if there is no money, domain name resolution using DNS polling strategy, can achieve similar results, but slightly poor reliability.

4. Database problem

Conventional enterprise applications, traditional relational data is still the mainstream, but no-sql after these years of development, technology is increasingly mature, some non-critical data can be appropriately adopted No-sql database, such as: System log, message history such relatively independent, and rapid growth of data, Consider storing in a distributed open source file system such as No-sql db or even HDFs, TFS.

If the system data volume reaches the upper limit of the single-machine RDBMS, consider the sharding scheme as early as possible, at present MySQL is more mature in this aspect, other database is not good to say.

5. Performance

Web server, app server these generally can be expanded horizontally through the cluster to meet the daily growth of performance requirements. The biggest hurdle is db, if the scale really reaches the upper limit of the DB, consider switching to distributed db or migrating to the cloud.

Enterprise Application Common Architecture diagram