如何画出企业系统架构图

该技术架构图是本人根据多年企业技术架构经验而制定，是企业技术的总架构图，希望对CTO们有所借鉴。

 简单说明：

1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境                            

2.企业集成平台是以基础业务应用为基础服务于上层平台和基础业务应用的高度集成平台         

3.数据中心是企业公共数据的集中管理比如用户数据、企业编码，可以通过数据集成平台或服务集成平台分发给其他应用     

项目做了不少,都没画过架构图,这次被要求画图,画的很丑,请大家看图本身包含的系统架构信息

一、架构整体图

　　

   1、核心是两库一线

　　1.1 接口总线

　　　　所有算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是为了解决某一大类问题的

　　1.2 代码库

　　　　代码库包含现接口总线中接口的各种实现

　　1.3 应用库

　　　　提供用户的界面或者提供给外部的服务

　　　　是通过容器配置调用算法库中的代码来实现的各种应用          

二、应用关系图

       1、应用通过配置从应用库中组装出自己的应用系统

       2、应用本身之外的东西尽量使用拦截器处理(授权访问、权限数据推送、异常处理、缓存、日志等)

       3、使用消息队列做高并发应用支撑(秒杀类似应用)

       4、使用分布式任务系统做周期作业、数据维护、数据计算等

ENode架构图

 

什么是ENode

ENode是一个.NET平台下，纯C#开发的，基于DDD,CQRS,ES,EDA,In-Memory架构风格的，可以帮助开发者开发高并发、高吞吐、可伸缩、可扩展的应用程序的一个应用开发框架。

• 开源项目地址：https://github.com/tangxuehua/enode
• 作者博客地址：http://www.cnblogs.com/netfocus/category/496012.html
• QQ交流群号：185916873
• 微信公众号：ENode

ENode框架特色

1. 一个DDD开发框架，完美支持基于六边形架构思想的开发
2. 实现CQRS架构思想，并且框架提供C端命令的处理结果的返回，支持同步返回和异步返回
3. 内置Event Sourcing（ES）架构模式，让C端的数据持久化变得通用化
4. 聚合根常驻内存，in-memory domain model
5. 聚合根的处理基于Command Mailbox, Event Mailbox的思想，类似Actor Model, Actor Mailbox
6. 严格遵守聚合内强一致性、聚合之间最终一致性的原则
7. Group Commit Domain event
8. 基于聚合根ID+事件版本号的唯一索引，实现聚合根的乐观并发控制
9. 框架保证Command的幂等处理
10. 通过聚合根ID对命令或事件进行路由，做到最小的并发冲突、最大的并行处理
11. 消息发送和接收基于分布式消息队列EQueue，支持分布式部署
12. 基于事件驱动架构范式（EDA，Event-Driven Architecture）
13. 基于队列的动态扩容/缩容
14. EventDB中因为存放的都是不可变的事件，所以水平扩展非常容易，框架可内置支持
15. 支持Process Manager（Saga），以支持一个用户操作跨多个聚合根的业务场景，如订单处理，从而避免分布式事务的使用
16. ENode实现了CQRS架构面临的大部分技术问题，让开发者可以专注于业务逻辑和业务流程的开发，而无需关心纯技术问题

晚上把公司应用的架构结合之前研究的东西梳理了下，整理了一张架构规划图，贴在这里备份

下面是个人理解的做架构的几个要点：

1、系统安全

这是首要考虑的，以这张图为例，网络划分为3个区：

a) DMZ区可以直接公网访问，也可以 与App Core区互通，但不能直接与DB Core区互通 (通常这里放置 反向代理Web服务器)

b) App Core区能与DMZ区、DB Core区互通，但是无法直接从公网访问 (通常这里放置 应用服务器、中间件服务器之类)

c) DB Core区仅与App Core区互通 (通常这里放置 核心数据库)

2、尽量消除单点故障

上图中，除了“硬件负载均衡”节点外，其它节点都可以部署成集群（DB有点特殊，传统RDBMS要实现分布式/集群还是比较困难的，要看具体采用的数据库产品，并非所有数据库都能方便的做Sharding），Jboss本身可以通过Domain模式+mod_cluster实现集群、Redis通过Master/Slave以Sentinel方式可以实现HA、IBM MQ本身就支持集群、FTP Server配合底层储存阵列也可以做到HA、Nginx静态资源服务器自不必说

3、成本

尽量采用开源成熟产品，jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的选择。硬件负载均衡通常成本不低，但是效果明显，如果实在没钱，域名解析采用DNS轮询策略，也能达到类似效果，只不过可靠性略差。

4、Database问题

常规企业应用中，传统关系型数据仍然是主流，但是no-sql经过这几年发展，技术也日渐成熟了，一些非关键数据可以适当采用no-sql数据库，比如：系统日志、报文历史记录这类相对比较独立，而且增长迅速的数据，可以考虑存储到no-sql db甚至HDFS、TFS等分布式开源文件系统中。

如果系统数据量级达到单机RDBMS的上限，尽早考虑Sharding方案，目前mysql在这方面比较成熟，其它数据库就不好说了。

5、性能

web server、app server这些一般都可以通过集群实现横向扩张，满足性能日常增长的需求。最大的障碍还是DB，如果规模真达到了DB的上限，还是考虑换分布式DB或者迁移到“云”上吧。

HBase 系统架构图

　　

　　组成部件说明 　　Client：    　　使用HBase RPC机制与HMaster和HRegionServer进行通信    　　Client与HMaster进行通信进行管理类操作    　　Client与HRegionServer进行数据读写类操作    　　Zookeeper：    　　Zookeeper Quorum存储-ROOT-表地址、HMaster地址    　　HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况    　　Zookeeper避免HMaster单点问题    　　HMaster：    　　HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master在运行    　　主要负责Table和Region的管理工作：    　　1 管理用户对表的增删改查操作    　　2 管理HRegionServer的负载均衡，调整Region分布    　　3 Region Split后，负责新Region的分布    　　4 在HRegionServer停机后，负责失效HRegionServer上Region迁移    　　HRegionServer：    　　HBase中最核心的模块，主要负责响应用户I/O请求，向HDFS文件系统中读写数据

　　

　　HRegionServer管理一些列HRegion对象；   　　每个HRegion对应Table中一个Region，HRegion由多个HStore组成；  　　每个HStore对应Table中一个Column Family的存储；    　　Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效

　　HStore：    　　HBase存储的核心。由MemStore和StoreFile组成。    　　MemStore是Sorted Memory Buffer。用户写入数据的流程：

　　

　　Client写入 -> 存入MemStore，一直到MemStore满 -> Flush成一个StoreFile，直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除 -> 当StoreFiles Compact后，逐步形成越来越大的StoreFil