1、开篇
前期咱们针对架构准备阶段及需求分析这块咱们写了2篇内容《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-下篇》内容来展开说明。html
本篇主将详细的阐述架构设计过程当中概要架构设计要点来和你们共同交流，掌握后续如何强化概要架构设计在架构设计中做用，帮助咱们快速确认架构的方向及核心大框架。web
在阐述具体的概要架构工做方法以前，还请你们先参考咱们限定的业务场景：面试
一、HRMS系统的介绍？（涵盖哪些功能？价值和做用是什么？行业什么状况？）缓存
请阅读《HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍》安全
二、本章分析的内容将围绕4类企业表明的业务场景，（区分不一样规模企业的关注点，规模将决定系统的设计方案）服务器
本篇将围绕4类企业表明来阐述不一样规模企业对于HRMS的需求及应用架构
- A、100人如下的中小企业
- B、500人如下的大中型企业
- C、1000人以上的集团化大企业
- D、全球类型的公司体系（几万人）
三、架构师在设计该系统时的职责及具有的核心能力是什么？框架
请阅读《系统架构系列-开篇介绍》运维
1、关于概要架构阶段
1.一、概要架构的定义
概念架构就是对系统设计的最初构想，就是把系统最关键的设计要素及交互机制肯定下来，而后再考虑具体的技术应用，设计出实际架构。概念架构阶段主抓大局，不拘小节，不过度关注设计实现的细节内容。工具
概要架构阶段的特色：
Ø知足“架构=组件+交互”的基本定义(全部架构都逃离不了该模式)
Ø对高层组件的“职责”进行笼统界定，并给出高层组件的相互关系
Ø不该涉及接口细节
在讲具体的概要架构设计实践以前，请你们思考如下问题：
Ø不一样系统的架构，为何不一样？
Ø架构设计中，应什么时候确立架构大方向的不一样？（功能、质量、约束
1.二、行业现状
1.2.一、误将“概要架构”等同于“理想架构”
架构设计是功能需求驱动的，对吗？
架构设计是用例驱动的，对吗？
实际上架构设计的驱动力：功能+质量+约束
1.2.二、误把“阶段”当“视图”
概要架构阶段仍是概念视图？
阶段体现前后关系，视图体现并列关系
概要架构阶段根据重大需求、特殊需求、高风险需求造成稳定的高层架构设计成果
1.三、主要工做内容及目标
概念架构是一个架构设计阶段，必须在细化架构设计阶段以前，针对重大需求，特点需求、高风险需求、造成文档的高层架构设计成果。
重大需求塑造概念架构，这里的重大需求涵盖功能、质量、约束等3类需求的关键内容。
若是只考虑功能需求来设计概念架构，将致使概念架构沦为“理想化的架构”，这个脆弱的架构不久就会面临“大改”的压力，甚至直接致使项目失败。
2、概要架构阶段的方法及科学实践过程是什么？
总体可分为3个阶段：
一、经过鲁棒图：初步设计的目标就是发现职责，运用“职责协做链”原理画鲁棒图
二、高层分割：运用成熟的经验及方法论，结合场景选择合适的架构模式来肯定系统的层级关系
三、质疑驱动：考虑非功能性需求来不断驱动概要架构设计过程。
2.一、初步设计的目标就是发现职责，运用“职责协做链”原理画鲁棒图
鲁棒图的三种对象：
•边界对象对模拟外部环境和将来系统之间的交互进行建模。边界对象负责接 收外部输入、处理内部内容的解释、并表达或传递相应的结果。
•控制对象对行为进行封装，描述用例中事件流的控制行为。
•实体对象对信息进行描述，它每每来自领域概念，和领域模型中的对象有良好的对应关系。
初步设计原则
•初步设计的目标是“发现职责”，为高层切分奠基基础
•初步设计“不是”必须的，但当“待设计系统”对架构师而言并没有太多直接 经验时，则强烈建议进行初步设计
•基于关键功能（而不是对全部功能）、借助鲁棒图（而不是序列图，序列图太细节）进行初 步设计
关于这几个对象的区别，请参考《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》中有描述鲁棒图的基本用法说明。后续本文将直接使用再也不复述具体的用法。
你们看完鲁棒图发现鲁棒图也有实体、控制及边界对象，怎么这么相似web系统时用到的MVC模式，那么咱们这里对比下这2个模式的异同点:
经过上面的对比咱们发现，鲁棒图可以更全面的体现架构设计过程当中涉及的内容，单独的架构模式更侧重其中的部分架构层次，好比逻辑架构采起MVC的模式。
2.二、高层分割（概念架构造成的具体操做方法）
1）、直接分层
2）、先划分为子系统，再针对每一个子系统分层
针对高层分割，咱们能够采起分阶段的模式来进行落地实践：
一、直接划分层次：直接把系统划分为多个层次，梳理清晰各层次间的关联关系
二、分为2个阶段：先划分为多个子系统，而后再梳理子系统的层次，梳理清晰没格子系统的层次关系
针对分层模式的引入，这里分享几类划分模式及方法：
一、逻辑层：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性
二、物理层：分布部署在不一样机器上
三、通用性分层：通用性越多，所处层次越靠下
2.2.一、Layer：逻辑层
Layer：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性。Layer是逻辑上组织代码的形式。好比逻辑分层中表现层，服务层，业务层，领域层，他们是软件功能来划分的。并不指代部署在那台具体的服务器上或者，物理位置。
多层Layer架构模式
诸如咱们常见的三层架构模式，三层架构(3-tier architecture) 一般意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最多见，也是最重要的一种结构。微软推荐的分层式结构通常分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
逻辑层次的架构能帮助咱们解决逻辑耦合，达到灵活配置，迁移。 一个良好的逻辑分层能够带来：
A、逻辑组织代码/代码逻辑的清晰度
B、易于维护（可维护性）
C、代码更好的重用（可重用性）
D、更好的团队开发体验（开发过程支持）
2.2.二、Tier：物理层
Tier：物理层，各分层分布部署在不一样机器上，Tier这指代码运行部署的具体位置，是一个物理层次上的划为，Tier就是指逻辑层Layer具体的运行位置。因此逻辑层能够部署或者迁移在不一样物理层，一个物理层能够部署运行多个逻辑层。
Tier指代码运行的位置，多个Layer能够运行在同一个Tier上的，不一样的Layer也能够运行在不一样的Tier上，固然，前提是应用程序自己支持这种架构。以J2EE和.NET平台为例，大多数时候，不一样的Layer之间都是直接经过DLL或者JAR包引用来完成调用的（例如：业务逻辑层须要引用数据访问层），这样部署的时候，也只能将多个Layer同时部署在一台服务器上。相反，不一样的Layer之间若是是经过RPC的方式来实现通讯调用的，部署的时候，即可以将不一样的Layer部署在不一样的服务器上面，这也是很常见的解耦设计。
一个良好的物理架构能够带来：
A、性能的提高
B、可伸缩性
C、容错性
D、安全性
2.2.三、通用性分层
采起通用性分层模式，原则是通用性越多，所处层次越靠下
而且各层的调用关系是自上而下的，越往下通用性越高。
2.三、质疑驱动，不断完善系统架构（质量属性及约束决定了架构的演变）
基于系统中的重大功能来塑造概念架构的高层框架，过程当中须要经过质量及约束等非功能性需求不断质疑初步的概念架构，逐步让这个概念架构完善，可以知足及支撑各种质量及约束的要求。具体的操做方法咱们能够采起以前篇幅《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》中介绍的 “目标-场景-决策表” 来实现。
Ø经过“目标-场景-决策表”分析非功能需求：
经过分析关键的质量及约束内容，给出具体的场景及应对策略，梳理出清晰的决策表，在概念架构阶段融合决策表中给出的方案，最终给出初步的概念架构设计。
3、基于前面分析的HRMS系统？咱们如何下手开始？
结合前面讲的需求梳理的要点内容，咱们结合HRMS系统来进行应用实践，逐步造成概要架构设计。
A、基于RelationRose 来画出鲁棒图、肯定系统的边界及关键内容
1)、分析系统中的参与者及应用功能边界：
基于上面咱们可以发现咱们的核心功能点：
组织管理：主要实现对公司组织结构及其变动的管理；对职位信息及职位间工做关系的管理，根据职位的空缺进行人员配备；按照组织结构进行人力规划、并对人事成本进行计算和管理，支持生成机构编制表、组织结构图等
人事档案：主要实现对员工从试用、转正直至解聘或退休整个过程当中各种信息的管理，人员信息的变更管理，提供多种形式、多种角度的查询、统计分析手段
劳动合同：提供对员工劳动合同的签定、变动、解除、续订、劳动争议、经济补偿的管理。可根据须要设定试用期、合同到期的自动提示
招聘管理：实现从计划招聘岗位、发布招聘信息、采集应聘者简历，按岗位任职资格遴选人员，管理面试结果到通知试用的全过程管理
薪酬福利：工资管理系统适用于各种企业、行政、事业及科研单位，直接集成考勤、绩效考核等数据，主要提供工资核算、工资发放、经费计提、统计分析等功能。支持工资的屡次或分次发放；支持代扣税或代缴税；工资发放支持银行代发，提供代发数据的输出功能，同时也支持现金发放，提供分钱清单功能。经费计提的内容和计提的比率能够进行设置；福利管理系统提供员工的各项福利基金的提取和管理功能。主要包括定义基金类型、设置基金提取的条件，进行基金的平常管理，并提供相应的统计分析，基金的平常管理包括基金按期提取、基金的补缴、转入转出等。此外，提供向相关管理机关报送相关报表的功能
行政管理：主要提供对员工出勤状况的管理，帮助企业完善做业制度。主要包括各类假期的设置、班别的设置、相关考勤项目的设置，以及调班、加班、公出、请假的管理、迟到早退的统计、出勤状况的统计等。提供与各种考勤机系统的接口，并为薪资管理系统提供相关数据。支持通知公告分发，支持会议室/车辆等资源预约并同步日历，支持调研和投票问卷，支持活动管理的报名/签到/统计等，支持人员的奖惩管理并与人事档案关联，支持活动的抽奖管理等
培训管理：根据岗位设置及绩效考核结果，肯定必要的培训需求；为员工职业生涯发展制定培训计划；对培训的目标、课程内容、授课教师、时间、地点、设备、预算等进行管理，对培训人员、培训结果、培训费用进行管理
绩效管理：经过绩效考核能够评价人员配置和培训的效果、对员工进行奖惩激励、为人事决策提供依据。根据不一样职位在知识、技能、能力、业绩等方面的要求，系统提供多种考核方法、标准，容许自由设置考核项目，对员工的特征、行为、工做结果等进行定性和定量的考评
配置管理：系统中为了加强系统的兼容性及灵活性，增长了诸多系统开关及配置，为后续知足各种场景提供支撑。其中须要有配置项的动态分类、动态增长、修改等功能
权限管理： 通用权限管理系统，支撑组织、员工、角色、菜单、按钮、数据等涵盖功能及数据全面的权限管理功能
流程管理：提供工做流引擎服务，支持自定义表单及流程，全面支撑HRMS系统中的审批流。
人力资源规划分析：提供全方位的统计分析功能，知足企业人力资源管理及规划，为后续的经营决策提供数据依据。
2)、系统边界
基于上述核心功能点，咱们能够梳理出系统的边界，包含以下几个方面：
i、管理员的系统边界
因为管理员的角色定位已经作了限定，因此他须要有专门的运维管理后台，这个后台提供的功能和业务操做人员的后台功能和界面是彻底不一样的，因此须要单独的入口，其中的功能模块也是有区别的。因此咱们能够得出管理员使用系统时的接入方式和边界。
ii、HR的系统边界
HR的角色承担业务管理的相关职责，诸如HR模块中的审批环节，他们既有业务发起的操做又有审批环节的操做，因此相对来讲HR角色的使用边界会更普遍，相比员工来讲。咱们发现HR在使用时须要有单独的系统入口，而且分配给他们对应的业务模块及功能。
iii、员工的系统边界
对于员工来讲，HRMS系统中只有部分模块式能够操做使用的，诸如考勤、报销、绩效、查看及维护我的信息等，其余的信息都是由HR填写后用户能够查看，因此从操做便捷来看，员工与HR在业务系统入口上能够是统一入口，经过权限来限制访问边界便可。
iv、公司管理者的边界
公司的管理者相比员工具备相应的业务及数据管理权限，同时会在审批流环节中承担审核者的身份，诸多业务流程都和管理者相关，因此相比员工来讲，公司管理者的业务及操做权限较大，更多的上下级管理方面的业务内容较多，同时还能够完成员工角色操做的相关业务。
3)、数据对象
i、基础数据：系统包含的元数据、服务管理、日志、模块、基础配置、数据字典、系统管理等基础数据管理
ii、业务数据：涵盖机构、员工、HRMS系统业务及流程数据、外部第三方业务联动数据等
iii、其余数据：涵盖诸如文件、图片、视频等其余类型的数据；统计分析后的结果数据；与第三方系统交互或留存的数据等相关内容。其余诸如log日志等数据信息。
B、划分高层子系统
咱们基于上面鲁棒图分析后的核心需求，咱们给出系统的宏观的架构轮廓，这里仅考虑用户角色及职责链、从而造成上述的高层分割。
C、质量需求影响架构的基本原理：进一步质疑
结合前面咱们已经梳理过的关键的质量及约束，具体请参考《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-下篇》，因为篇幅关系我就不详细列举，下面基于这些质量属性及约束咱们来进一步完善概要架构：
1)、考虑关键质量属性中的持续可用性及可伸缩性，得出概要架构的中间成果：
2)、考虑关键质量属性中的互操做性，进一步优化概要架构的中间成果：
3)、考虑高性能，除了高负载，还须要考虑静态化、缓存等提高系统性能：
上面基本造成了一个概要架构的雏形，不过这还不够，咱们还有一项关键的内容没有分析，那就是系统约束，咱们须要将以前明确的关键约束进行分析拆解，转化为功能或质量要求：
D、分析约束影响架构的基本原理：直接制约、转化为功能或质量需求
分析上述表格的内容，结合上几轮分析后给出的概要架构进行验证，看看这些约束会不会影响该架构内容，而后进行优化调整：
i、业务环境及约束：目前来看，上述概要架构能够支持,不会对于当前的概要架构形成影响。
ii、使用环境约束：以前拟定的PC、App端访问模式已考虑了上述的场景，关于多语言在应用层细节设计时考虑便可。
iii、开发环境约束：概要架构还不涉及细节内容，当前的约束也不会对于架构产生较大影响
iv、技术环境约束：无影响，属于细节层面
E、基于上面几部走，咱们获得了初步的概要架构，基本上符合功能、质量及约束的各种要求及场景，得出如下概要架构设计图。
4、概要架构阶段要点总结
基于前面对于概要架构设计推演过程的实践，咱们总结概要架构过程的3个核心要点内容以下：
一、首先，须要分析找到HRMS系统中的关键功能、质量及约束
二、其次，利用鲁棒图找到系统的用户、关键功能及职责链，造成初步的子系统的拆分、过程当中借助高层分割造成分层结构，不断经过质疑+解决方案的模式，应对及完善质量及约束的要求。
三、最后，经过一、2步实践过程，最终推导出初步的概要架构，为下一步的细化架构提供基础。
但愿你们经过上面示例的展现，为你们后续在系统架构设计实践的过程当中提供一些帮助。
5、更多信息
关于更多的系统架构方面的知识，我已创建了交流群，相关资料会第一时间在群里分享，欢迎你们入群互相学习交流：