目录

一、总体设计

（一）总体设计的任务

（二）总体设计的概念

（三）结构设计的准则

二、详细设计

         （一）详细设计的原则

（二）详细设计的工具

三、总体设计、详细设计文档的重要性

---

需求分析确定了系统的开发目标，下一步工作就是软件设计。软件设计可以进一步地 分为两个阶段：总体设计和详细设计。   

第二章 网络设计原则

我们在进行网络设计时，本着以下几点进行设计：

（1）高性能

随着业务的增加和计算机技术的发展，接入局域网的用户将越来越多，终端和工作站的处理能力越来越强，以及图形图像和多媒体的应用越来越广泛，要求每个用户实际可用带宽很高才能使网络通信流畅，网络将成为提供多种业务的统一网络平台，并应该为不同的业务提供服务质量保证（QoS）。因此，设计方案时充分了考虑将来业务量的增大，保证当前及今后一定时期内网络的高效与通畅。

（2）可扩展性

网络要能满足用户当前需求以及将来需求的增长、新技术发展等变化。因此在保护原有的投资同时，要保证用户数的增加，以及用户随时随地增加设备、增加网络功能等。随着应用规模的发展，系统能灵活方便地进行硬件或软件系统的扩展和升级。

在网络设计时应考虑到网络在未来几年中的发展，使得网络的扩展可以在现有网络的基础上通过简单的增加设备和提高电路带宽的方法来解决，以适应不断增长的业务需求，保护本次网络建设的投资。

（3）可靠性和安全性

网络的可靠性是网络设计中需要考虑的一个主要原则。作为信息系统应用的依赖和基础，要求系统连续安全可靠地运行，所以在系统结构设计中选用高可靠性网络产品，合理设计网络架构，尽可能利用成熟技术，网络关键部分要制定可靠的网络备份策略，对于重要的网络节点应采用先进可靠的容错技术，以保证网络系统具有故障自愈的能力，最大限度地支持专网内各业务系统的正常运行。

安全性：通过VPN网络、内外网隔离、加密、防火墙等技术。

（4）标准开放性

支持国际上通用标准的网络协议、国际标准的大型的动态路由协议等开放协议，有利于保证与其它网络（如资源数据库、金融网络）之间平滑连接互通，以及将来网络的扩展。

（5）可管理性及易维护性

对网络实行集中监测、分权管理，并统一分配带宽资源。选用先进的网络管理平台，具有对设备、端口等的管理、流量统计分析，及可提供故障自动报警。

兵团电子政务外网在方案设计和设备选型中将预留接口，保证与新疆自治区在骨干层面（兵团级－师（市）级）的网络互联互通。

6）对业务流量模型变化的适应性

未来网络中的业务流量模型将会业务的发展而不断发生变化。因此在进行网络设计时应该考虑网络结构对未来业务流量模型的变化的适应性，可以根据流量的变化方便的进行调整。

7）网络管理的复杂程度

鉴于IP网络越来越大，未来的网络管理的工作量也会变的越来越大和复杂。因此在网络设计应该考虑网络管理的因素，使得故障定位和流量调整的难度和复杂性降低。

8）流量的负载分担

整个网络的设计，必须具有多路由选择、路由迂回、路由备份的能力，以防止因单路由或单节点的损坏而造成全网或非损坏节点的中断。同时，网络禁止出现路由循环、路由不被利用或很少利用的情况，尽可能地做到负载分担。

9）对新业务的支持程度

随着传输技术的不断发展，以及基于IP的业务种类的增加，采用IP 网络技术建立支持多种业务的统一网络平台已经成为一种经济的，高效率的做法。

网络将成为提供多种业务的统一网络平台，在网络设计时应该是网络结构能够适合今后城域网可能提供的新业务。

一 前言

  微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢？如下:

• AKF 拆分原则
• 前后端分离原则
• 无状态服务
• RestFul 的通信风格

二 AKF 拆分原则

   有句挺流行的话:没有什么事是一顿烧烤解决不了的，如果有，那就两顿....。这跟我们之前设计可扩展的系统架构的理念很相像，

通过加机器就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。这个理念在当前也得到了广泛的认可！对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但是随着现在业务的更迭不穷以及功能模块的不断拓展，许多系统在设计的时候并没有充分考虑到这一点，所以如果架构重设，必然会导致财力跟人力的浪费。对此，《可扩展的艺术》一书提出了一
个更加系统的可扩展模型—— AKF  可扩展立方（Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。

• Y 轴(功能) —— 关注应用中功能划分，基于不同的业务拆分
• X 轴(水平扩展) —— 关注水平扩展，也就是”加机器解决问题”
• Z 轴(数据分区) —— 关注服务和数据的优先级划分，如按地域划分

2.1  Y  轴（功能）

Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是  服务化架构(SOA) 。比如对于一个电子商务平台，我们可以拆分成不同的服务，组成下面这样的架构：

但通过观察上图容易发现，当服务数量增多时，服务调用关系变得复杂。为系统添加一个新功能，要调用的服务数也变得不可控，由此引发了服务管理上的混乱。所以，一般情况下，需要采用服务注册的机制形成服务网关来进行服务治理。系统的架构将变成下图所示：

2.2 X 轴(水平扩展)

X 轴扩展与我们前面朴素理念是一致的，通过绝对平等地复制服务与数据，以解决容量和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均衡的模式。为了提升单个服务的可用性和容量，  对每一个服务进行 X  轴扩展划分 

2.3  Z  轴( 数据分区)

Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产。这就是一种 Z 轴扩展。

工程领域常见的 Z  轴扩展有以下两种方案：
1.单元化架构
在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的 Y 轴扩展的 SOA 架构，客户端对服务端节点的选择一般是随机的，但是，如果在此加上 Z 轴扩展，那服务节点的选择将不再是随机的了，而是每个单元自成一体。如下图：

2  数据分区
为了性能数据安全上的考虑，我们将一个完整的数据集按一定的维度划分出不同的子集。 一个分区（Shard），就是是整体数据集的一个子集。比如用尾号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式：
数据类型（如：业务类型）
数据范围（如：时间段，用户 ID）
数据热度（如：用户活跃度，商品热度）
按读写分（如：商品描述，商品库存）

举个例子:比如美团，滴滴遍布全国，各个城市的业务进展不太一样，所以可以根据城市来进行数据分区。

三 前后端分离原则

   这个我们应该很常见，前端做前端的事情，后端做后端的业务模块，分工更加明确。

那么前后段分离有什么好处呢?

这种分离方式有几个好处：

• 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前段的用户体验优化效果更好。
• 分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
• 前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

四 无状态服务

     什么是状态？

     如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。更好的说明见下图：

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。这样对于业务的拓展起到了至关重要的作用

五 RestFul通讯风格

作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

1.  无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密，有现成的成熟方案 HTTPS 即可。
2.  JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
3. 语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些RPC 框架生态更完善。