软件各种系统架构图.docx

软件各种系统架构图.docx

《软件各种系统架构图.docx》由会员分享，可在线阅读，更多相关《软件各种系统架构图.docx（18页珍藏版）》请在冰豆网上搜索。

软件各种系统架构图

软件各种系统架构图

LT

软件各种系统架构图

发布一企业技术架构图，供大家参考。

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

简单说明：

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

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

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

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

一、架构整体图　　

1、核心是两库一线

　　1.1接口总线

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

　　1.2代码库

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

　　1.3应用库

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

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

原则GroupCommitDomainevent基于聚合根ID+事件版本号的唯一索引，实现聚合根的乐观并发控制框架保证Command的幂等处理通过聚合根ID对命令或事件进行路由，做到最小的并发冲突、最大的并行处理消息发送和接收基于分布式消息队列EQueue，支持分布式部署基于事件驱动架构范式（EDA，Event-DrivenArchitecture）基于队列的动态扩容/缩容EventDB中因为存放的都是不可变的事件，所以水平扩展非常容易，框架可内置支持支持ProcessManager（Saga），以支持一个用户操作跨多个聚合根的业务场景，如订单处理，从而避免分布式事务的使用ENode实现了CQRS架构面临的大部分技术问题，让开发者可以专注于业务逻辑和业务流程的开发，而无需关心纯技术问题

晚上把公司应用的架构结合之前研究的东西梳理了下，整理了一张架构规划图，贴在这里备份下面是个人理解的做架构的几个要点：

1、系统安全

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

a）DMZ区可以直接公网访问，也可以与AppCore区互通，但不能直接与DBCore区互通（通常这里放置反向代理Web服务器）

b）AppCore区能与DMZ区、DBCore区互通，但是无法直接从公网访问（通常这里放置应用服务器、中间件服务器之类）

c）DBCore区仅与AppCore区互通（通常这里放置核心数据库）

2、尽量消除单点故障

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

3、成本

尽量采用开源成熟产品，jboss、redis、nginx、apache、mysql、rabbitMQ都是很好的选择。

硬件负载均衡通常成本不低，但是效果明显，如果实在没钱，域名解析采用DNS轮询策略，也能达到类似效果，只不过可靠性略差。

4、Database问题

常规企业应用中，传统关系型数据仍然是主流，但是no-sql经过这几年发展，技术也日渐成熟了，一些非关键数据可以适当采用no-sql数据库，比如：

系统日志、报文历史记录这类相对比较独立，而且增长迅速的数据，可以考虑存储到no-sqldb甚至HDFS、TFS等分布式开源文件系统中。

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

5、性能

webserver、appserver这些一般都可以通过集群实现横向扩张，满足性能日常增长的需求。

最大的障碍还是DB，如果规模真达到了DB的上限，还是考虑换分布式DB或者迁移到“云”上吧。

HBase系统架构图

　　组成部件说明　　Client：

　　使用HBaseRPC机制与HMaster和HRegionServer进行通信　　Client与HMaster进行通信进行管理类操作　　Client与HRegionServer进行数据读写类操作　　Zookeeper：

　　ZookeeperQuorum存储-ROOT-表地址、HMaster地址

　　HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况　　Zookeeper避免HMaster单点问题　　HMaster：

　　HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的MasterElection机制保证总有一个Master在运行　　主要负责Table和Region的管理工作：

　　1管理用户对表的增删改查操作　　2管理HRegionServer的负载均衡，调整Region分布　　3RegionSplit后，负责新Region的分布　　4在HRegionServer停机后，负责失效HRegionServer上Region迁移　　HRegionServer：

　　HBase中最核心的模块，主要负责响应用户I/O请求，向HDFS文件系统中读写数据

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

　　HStore：

　　HBase存储的核心。

由MemStore和StoreFile组成。

　　MemStore是SortedMemoryBuffer。

用户写入数据的流程：

　　Client写入->存入MemStore，一直到MemStore满->Flush成一个StoreFile，直至增长到一定阈值->触发Compact合并操作->多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除->当StoreFilesCompact后，逐步形成越来越大的StoreFile->单个StoreFile大小超过一定阈值后，触发Split操作，把当前RegionSplit成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

由此过程可知，HBase只是增加数据，有所得更新和删除操作，都是在Compact阶段做的，所以，用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能。

　　HLog　　引入HLog原因：

　　在分布式系统环境中，无法避免系统出错或者宕机，一旦HRegionServer意外退出，MemStore中的内存数据就会丢失，引入HLog就是防止这种情况　　工作机制：

　　每个HRegionServer中都会有一个HLog对象，HLog是一个实现WriteAheadLog的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件（已持久化到StoreFile中的数据）。

当HRegionServer意外终止后，HMaster会通过Zookeeper感知，HMaster首先处理遗留的HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在Load

Region的过程中，会发现有历史HLog需要处理，因此会ReplayHLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

　　HBase存储格式　　HBase中的所有数据文件都存储在HadoopHDFS文件系统上，格式主要有两种：

　　1HFileHBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile　　2HLogFile，HBase中WAL（WriteAheadLog）的存储格式，物理上是Hadoop的Sequence

File

　　HFile

　　图片解释：

　　HFile文件不定长，长度固定的块只有两个：

Trailer和FileInfo　　Trailer中指针指向其他数据块的起始点　　FileInfo中记录了文件的一些Meta信息，例如：

AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY等　　DataIndex和MetaIndex块记录了每个Data块和Meta块的起始点　　DataBlock是HBaseI/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block

Cache机制　　每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询　　每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成,Magic内容就是一些随机数字，目的是防止数据损坏

　　HFile里面的每个KeyValue对就是一个简单的byte数组。

这个byte数组里面包含了很多项，并且有固定的结构。

　　KeyLength和ValueLength：

两个固定的长度，分别代表Key和Value的长度　　Key部分：

RowLength是固定长度的数值，表示RowKey的长度，Row就是RowKey　　ColumnFamilyLength是固定长度的数值，表示Family的长度　　接着就是ColumnFamily，再接着是Qualifier，然后是两个固定长度的数值，表示TimeStamp和KeyType（Put/Delete）　　Value部分没有这么复杂的结构，就是纯粹的二进制数据

　　HLogFile

　　HLog文件就是一个普通的HadoopSequenceFile，SequenceFile的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括sequencenumber和timestamp，timestamp是“写入时间”，sequencenumber的起始值为0，或者是最近一次存入文件系统中sequencenumber。

　　HLogSequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue

　　结束语：

这篇文章是我专门在网上弄下来的，算是hbase部分的终极篇吧，我的服务端的源码系列也要基于这个顺序来开展。

一．三层架构图

二．系统各层次职责

1.UI（UserInterface）层的职责是数据的展现和采集，数据采集的结果通常以Entityobject提交给BL层处理。

ServiceInterface侧层用于将业务或数据资源发布为服务（如WebServices）。

2.BL（BusinessLogic）层的职责是按预定的业务逻辑处理UI层提交的请求。

（1）BusinessFunction子层负责基本业务功能的实现。

（2）BusinessFlow子层负责将BusinessFunction子层提供的多个基本业务功能组织成一个完整的业务流。

（Transaction只能在BusinessFlow子层开启。

）

3．ResourceAccess层的职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。

（1）BEM（BusinessEntityManager）子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。

（2）DataAccess子层负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

DBAdapter子层负责屏蔽数据库类型的差异。

ORM子层负责提供对象－关系映射的功能。

Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。

（3）ServiceAccess子层用于以SOA的方式从外部系统获取资源。

注：

ServiceEntrance用于简化对Service的访问，它相当于Service的代理，客户直接使用ServiceEntrance就可以访问系统发布的服务。

ServiceEntrance为特定的平台（如Java、.Net）提供强类型的接口，内部可能隐藏了复杂的参数类型转换。

（4）ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。

4．Entity侧层跨越UI/BEM/ResourceManager层，在这些层之间传递数据。

Entity侧层中包含三类Entity，如下图所示：

三．Aspect

Aspect贯穿于系统各层，是系统的横切关注点。

通常采用AOP技术来对横切关注点进行建模和实现。

1．SecurtiyAspect：

用于对整个系统的Security提供支持。

2．ErrorHandlingAspect：

整个系统采用一致的错误/异常处理方式。

3．LogAspect：

用于系统异常、日志记录、业务操作记录等。

四．规则

1．系统各层次及层内部子层次之间都不得跨层调用。

2．Entityobject在各个层之间传递数据。

3．需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entityobject传递数据。

4．对于每一个数据库表（Table）都有一个DBEntityclass与之对应，针对每一个Entityclass都会有一个BEMClass与之对应。

5．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEMClass来提供支持。

6．对于相对简单的系统，可以考虑将BusinessFunction子层和BusinessFlow子层合并为一个。

7．UI层和BL层禁止出现任何SQL语句。

五．错误与异常

异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。

1．DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。

2．要明确区分业务执行的结果和系统异常。

比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。

但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。

3．在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。

比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。

4．UI层（包括Service层）除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。

六．项目组织目结构

以BAS系统为例。

1．主目录结构：

2．命名空间命名：

每个dll的根命名空间即是该dll的名字，如EAS.BL.dll的根命名空间就是EAS.BL。

每个根命名空间下面可以根据需求的分类而增加子命名空间，比如，EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。

3.包含众多子项目的庞大项目的物理组织：

核心子项目Core的位置：

Core子项目中包含一些公共的基础设施，如错误处理、权限控制方面等。

七．发布服务与服务回调

以EAS系统为例。

1．同UI层的Page一样，服务也不允许抛出任何异常，而是应该以返回错误码（int型，1表示成功，其它值表示失败）的形式来表明服务调用出现了错误，如果方法有返回值，则返回值以out参数提供。

2.如果BAS系统提供了WebService（Remoting）服务，则BAS必须提供BAS.Entrance.dll。

BAS.Entrance.dll封装了与BAS服务交换信息的通信机制，客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS提供的服务。

3．如果BAS需要通过WebService（Remoting）回调客户系统，则必须提供仅仅定义了接口的BAS.CallBack.dll，客户系统将引用该dll，实现其中的接口，并将其发布为服务，供BAS回调。

4．当WebService的参数或返回值需要是复杂类型――即架构图中的ServiceEntity，则ServiceEntity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。

WebService定义的方法中的复杂类型应该使用Xml字符串代替（注意，Entrance和CallBack接口对应服务的方法的参数是强类型的），而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

从上图中可以看出，Android系统架构为四层结构，从上层到下层分别是应用程序层、应用程序框架层、系统运行库层以及Linux内核层，分别介绍如下：

1）应用程序层

Android平台不仅仅是操作系统，也包含了许多应用程序，诸如SMS短信客户端程序、电话拨号程序、图片浏览器、Web浏览器等应用程序。

这些应用程序都是用Java语言编写的，并且这些应用程序都是可以被开发人员开发的其他应用程序所替换，这点不同于其他手机操作系统固化在系统内部的系统软件，更加灵活和个性化。

2）应用程序框架层

应用程序框架层是我们从事Android开发的基础，很多核心应用程序也是通过这一层来实现其核心功能的，该层简化了组件的重用，开发人员可以直接使用其提供的组件来进行快速的应用程序开发，也可以通过继承而实现个性化的拓展。

a）ActivityManager（活动管理器）

管理各个应用程序生命周期以及通常的导航回退功能

b）WindowManager（窗口管理器）

管理所有的窗口程序

c）ContentProvider（内容提供器）

使得不同应用程序之间存取或者分享数据

d）ViewSystem（视图系统）

构建应用程序的基本组件

e）NotificationManager（通告管理器）

使得应用程序可以在状态栏中显示自定义的提示信息

f）PackageManager（包管理器）

Android系统内的程序管理

g）TelephonyManager（电话管理器）

管理所有的移动设备功能

h）ResourceManager（资源管理器）

提供应用程序使用的各种非代码资源，如本地化字符串、图片、布局文件、颜色文件等

i）LocationManager（位置管理器）

提供位置服务

j）XMPPService（XMPP服务）

提供GoogleTalk服务

3）系统运行库层

从图中可以看出，系统运行库层可以分成两部分，分别是系统库和Android运行时，分别介绍如下：

a）系统库

系统库是应用程序框架的支撑，是连接应用程序框架层与Linux内核层的重要纽带。

其主要分为如下几个：

?

SurfaceManager：

执行多个应用程序时候，负责管理显示与存取操作间的互动，另外也负责2D绘图与3D绘图进行显示合成。

?

MediaFramework：

多媒体库，基于PacketVideoOpenCore;支持多种常用的音频、视频格式录制和回放，编码格式包括MPEG4、MP3、H.264、AAC、ARM。

?

SQLite:

小型的关系型数据库引擎

?

OpenGL|ES：

根据OpenGLES1.0API标准实现的3D绘图函数库

?

FreeType：

提供点阵字与向量字的描绘与显示

?

WebKit：

一套网页浏览器的软件引擎

?

SGL：

底层的2D图形渲染引擎

?

SSL：

在Andorid上通信过程中实现握手

?

Libc：

从BSD继承来的标准C系统函数库，专门为基于embeddedlinux的设备定制

b）Android运行时

Android应用程序时采用Java语言编写，程序在Android运行时中执行，其运行时分为核心库和Dalvik虚拟机两部分。

?

核心库

核心库提供了Java语言API中的大多数功能，同时也包含了Android的一些核心API,如android.os、、android.media等等。

?

Dalvik虚拟机

Android程序不同于J2me程序，每个Android应用程序都有一个专有的进程，并且不是多个程序运行在一个虚拟机中，而是每个Android程序都有一个Dalivik虚拟机的实例，并在该实例中执行。

Dalvik虚拟机是一种基于寄存器的Java虚拟机，而不是传统的基于栈的虚拟机，并进行了内存资源使用的优化以及支持多个虚拟机的特点。

需要注意的是，不同于J2me,Android程序在虚拟机中执行的并非编译后的字节码，而是通过转换工具dx将Java字节码转成dex格

式的中间码。

4）Linux内核层

Android是基于Linux2.6内核，其核心系统服务如安全性、内存管理、进程管理、网路协议以及驱动模型都依赖于Linux内核。

EntityFramework的全称是ADO.NETEntityFramework，是微软开发的基于ADO.NET的ORM（Object/RelationalMapping）框架。

EntityFramework的主要特点：

1.支持多种数据库（MicrosoftSQLServer,Oracle,andDB2）；

2.强劲的映射引擎，能很好地支持存储过程；

3.提供VisualStudio集成工具，进行可视化操作；

4.能够与ASP.NET,WPF,WCF,WCFDataServices进行很好的集成。

架构图一架构图2

　　刚刚来到一家新公司，首先会对项目进行一个大致了解，研究了两天了，有了个总体的把握了，下面就是我这个小菜鸟画的简单系统架构图！

　　　　有的时候架构庞大的吓人，有的时候架构一眼看穿，但里