《软件各种系统架构图》由会员分享，可在线阅读，更多相关《软件各种系统架构图（41页珍藏版）》请在金锄头文库上搜索。
1、软件各种系统架构图 发布一企业技术架构图，供大家参考。 该技术架构图是本人根据多年企业技术架构经验而制定，是企业技术的总架构图，希望对CTO们有所借鉴。 简单说明：1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境 2.企业集成平台是以基础业务应用为基础服务于上层平台和基础业务应用的高度集成平台 3.数据中心是企业公共数据的集中管理比如用户数据、企业编码，可以通过数据集成平台或服务集成平台分发给其他应用 项目做了不少,都没画过架构图,这次被要求画图,画的很丑,请大家看图本身包含的系统架构信息一、架构整体图 1、核心是两库一线1.1 接口总线所有算法功能抽象成接口
2、,其中大部分接口的方法都是泛型方法,是为了解决某一大类问题的1.2 代码库代码库包含现接口总线中接口的各种实现1.3 应用库提供用户的界面或者提供给外部的服务是通过容器配置调用算法库中的代码来实现的各种应用 二、应用关系图 1、应用通过配置从应用库中组装出自己的应用系统 2、应用本身之外的东西尽量使用拦截器处理(授权访问、权限数据推送、异常处理、缓存、日志等) 3、使用消息队列做高并发应用支撑(秒杀类似应用) 4、使用分布式任务系统做周期作业、数据维护、数据计算等 ENode架构图 什么是ENodeENode是一个.NET平台下，纯C#开发的，基于DDD,CQRS,ES,EDA,In-Memo
3、ry架构风格的，可以帮助开发者开发高并发、高吞吐、可伸缩、可扩展的应用程序的一个应用开发框架。开源项目地址：https:/ Sourcing（ES）架构模式，让C端的数据持久化变得通用化聚合根常驻内存，in-memory domain model聚合根的处理基于Command Mailbox, Event Mailbox的思想，类似Actor Model, Actor Mailbox严格遵守聚合内强一致性、聚合之间最终一致性的原则Group Commit Domain event基于聚合根ID+事件版本号的唯一索引，实现聚合根的乐观并发控制框架保证Command的幂等处理通过聚合根ID对命令或
4、事件进行路由，做到最小的并发冲突、最大的并行处理消息发送和接收基于分布式消息队列EQueue，支持分布式部署基于事件驱动架构范式（EDA，Event-Driven Architecture）基于队列的动态扩容/缩容EventDB中因为存放的都是不可变的事件，所以水平扩展非常容易，框架可内置支持支持Process Manager（Saga），以支持一个用户操作跨多个聚合根的业务场景，如订单处理，从而避免分布式事务的使用ENode实现了CQRS架构面临的大部分技术问题，让开发者可以专注于业务逻辑和业务流程的开发，而无需关心纯技术问题晚上把公司应用的架构结合之前研究的东西梳理了下，整理了一张架构规划
5、图，贴在这里备份下面是个人理解的做架构的几个要点：1、系统安全这是首要考虑的，以这张图为例，网络划分为3个区：a) DMZ区可以直接公网访问，也可以 与App Core区互通，但不能直接与DB Core区互通 (通常这里放置 反向代理Web服务器)b) App Core区能与DMZ区、DB Core区互通，但是无法直接从公网访问 (通常这里放置 应用服务器、中间件服务器之类)c) DB Core区仅与App Core区互通 (通常这里放置 核心数据库)2、尽量消除单点故障上图中，除了“硬件负载均衡”节点外，其它节点都可以部署成集群（DB有点特殊，传统RDBMS要实现分布式/集群还是比较困难的，
6、要看具体采用的数据库产品，并非所有数据库都能方便的做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问题常
7、规企业应用中，传统关系型数据仍然是主流，但是no-sql经过这几年发展，技术也日渐成熟了，一些非关键数据可以适当采用no-sql数据库，比如：系统日志、报文历史记录这类相对比较独立，而且增长迅速的数据，可以考虑存储到no-sql db甚至HDFS、TFS等分布式开源文件系统中。如果系统数据量级达到单机RDBMS的上限，尽早考虑Sharding方案，目前mysql在这方面比较成熟，其它数据库就不好说了。5、性能web server、app server这些一般都可以通过集群实现横向扩张，满足性能日常增长的需求。最大的障碍还是DB，如果规模真达到了DB的上限，还是考虑换分布式DB或者迁移到“云”上
8、吧。 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中可
9、以启动多个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对象； 每个HRegio
10、n对应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，直至增长到一定阈值 -> 触发
11、Compact合并操作 -> 多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除 -> 当StoreFiles Compact后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。由此过程可知，HBase只是增加数据，有所得更新和删除操作，都是在Compact阶段做的，所
12、以，用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能。HLog 引入HLog原因： 在分布式系统环境中，无法避免系统出错或者宕机，一旦HRegionServer意外退出，MemStore中的内存数据就会丢失，引入HLog就是防止这种情况 工作机制： 每个HRegionServer中都会有一个HLog对象，HLog是一个实现Write Ahead Log的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后，HMaster会通过Zookeep
13、er感知，HMaster首先处理遗留的HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在LoadRegion的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。HBase存储格式 HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，格式主要有两种： 1 HFile HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上Stor
14、eFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile 2 HLog File，HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的SequenceFileHFile图片解释： HFile文件不定长，长度固定的块只有两个：Trailer和FileInfo Trailer中指针指向其他数据块的起始点 File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等 Data Index和Meta Index块记录了每个Data块和Meta块的起始点 Data Block是HBase I/O的基本单元，为了提高效率，HRegionS
