发布一企业技术架构图，供大家参考。
该技术架构图是本人根据多年企业技术架构经验而制定，是企业技术的总架构图，希望对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框架特色
- 一个DDD开发框架，完美支持基于六边形架构思想的开发
- 实现CQRS架构思想，并且框架提供C端命令的处理结果的返回，支持同步返回和异步返回
- 内置Event Sourcing（ES）架构模式，让C端的数据持久化变得通用化
- 聚合根常驻内存，in-memory domain model
- 聚合根的处理基于Command Mailbox, Event Mailbox的思想，类似Actor Model, Actor Mailbox
- 严格遵守聚合内强一致性、聚合之间最终一致性的原则
- Group Commit Domain event
- 基于聚合根ID+事件版本号的唯一索引，实现聚合根的乐观并发控制
- 框架保证Command的幂等处理
- 通过聚合根ID对命令或事件进行路由，做到最小的并发冲突、最大的并行处理
- 消息发送和接收基于分布式消息队列EQueue，支持分布式部署
- 基于事件驱动架构范式（EDA，Event-Driven Architecture）
- 基于队列的动态扩容/缩容
- EventDB中因为存放的都是不可变的事件，所以水平扩展非常容易，框架可内置支持
- 支持Process Manager（Saga），以支持一个用户操作跨多个聚合根的业务场景，如订单处理，从而避免分布式事务的使用
- 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后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。 由此过程可知，HBase只是增加数据，有所得更新和删除操作，都是在Compact阶段做的，所以，用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能。
HLog 引入HLog原因： 在分布式系统环境中，无法避免系统出错或者宕机，一旦HRegionServer意外退出，MemStore中的内存数据就会丢失，引入HLog就是防止这种情况 工作机制： 每个HRegionServer中都会有一个HLog对象，HLog是一个实现Write Ahead Log的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后，HMaster会通过Zookeeper感知，HMaster首先处理遗留的HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。
HBase存储格式 HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，格式主要有两种： 1 HFile HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile 2 HLog File，HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence File
HFile
图片解释： 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的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制 每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询 每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏
HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项，并且有固定的结构。
KeyLength和ValueLength：两个固定的长度，分别代表Key和Value的长度 Key部分：Row Length是固定长度的数值，表示RowKey的长度，Row 就是RowKey Column Family Length是固定长度的数值，表示Family的长度 接着就是Column Family，再接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete） Value部分没有这么复杂的结构，就是纯粹的二进制数据
HLog File
HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。 HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue
结束语：这篇文章是我专门在网上弄下来的，算是hbase部分的终极篇吧，我的服务端的源码系列也要基于这个顺序来开展。
一．三层架构图
二．系统各层次职责
1.UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服务（如WebServices）。
2.BL（Business Logic）层的职责是按预定的业务逻辑处理UI层提交的请求。
（1）Business Function 子层负责基本业务功能的实现。
（2）Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。（Transaction只能在Business Flow 子层开启。）
3．ResourceAccess层的职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。
（1）BEM（Business Entity Manager）子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。
（2）DataAccess子层负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。
DB Adapter子层负责屏蔽数据库类型的差异。
ORM子层负责提供对象－关系映射的功能。
Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。
（3）ServiceAccess子层用于以SOA的方式从外部系统获取资源。
注： Service Entrance用于简化对Service的访问，它相当于Service的代理，客户直接使用Service Entrance就可以访问系统发布的服务。Service Entrance为特定的平台
