服务器架构设计，服务器架构

大家好，今天来为大家解答服务器架构设计这个问题的一些问题点，包括服务器架构也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~

系统架构设计包括哪些内容

系统架构组成部分有六个，如下：

业务架构；

应用架构；

集成架构；

数据架构；

技术架构；

1.业务架构

业务架构，是IT架构的基础，要从业务、产品视角，描述整个平台、或某个产品的实现。

业务架构是整个系统设计中最重要的架构，因为所有的系统设计都需要满足业务的需求，如果业务架构出现错误，将导致整个系统设计的失败。

业务架构是对于业务的框架性描述，一般分层展开，如运营支撑、作业执行、业务管控（监控、预警、风控）、决策分析。

业务架构中的数据，包括内部数据、外部系统数据、用户使用行为数据，共同组成一个数据流的闭环。

2.应用架构

从业务机构中来，分系统进行功能模块描述。

编写应用架构图时，往往需要站在整个平台视角，描述整个平台架构。应用架构可分为两种，一种是企业级应用架构，一种是单系统的应用架构。

3.集成架构

系统与外围交互系统之间的数据交换。

4.数据架构

数据架构主要解决三个问题：名列前茅，系统需要什么样的数据；第二，如何存储这些数据（数据的存储方式）；第三，如何进行数据架构设计（数据的展示方式）。

一套对存储数据的架构逻辑，它会根据各个系统应用场景、不同时间段的应用场景，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。

5.技术架构

包括网络安全、防火墙、负载均衡、网关、服务治理、开发服务、安全服务，以及业务模块用到的技术栈。

6.部署架构

包括分区部署，如互联网DMZ区、专线DMZ区、应用区、数据区等；核心组成部分的部署，包括web服务器、应用服务器、数据库等；网络安全策略部署，包括IP和端口、数据流向等。

服务器架构

按服务器的处理器架构(也就是服务器CPU所采用的指令系统)划分把服务器分为CISC架构服务器、RISC架构服务器和VLIW架构服务器三种。

折叠CISC服务器

CISC的英文全称为"Complex Instruction Set Computer",即"复杂指令系统计算机"，从计算机诞生以来，人们一直沿用CISC指令集方式。早期的桌面软件是按CISC设计的，所以，微处理器(CPU)厂商一直在走CISC的发展道路，包括Intel、AMD，还有其他一些已经更名的厂商，如TI(德州仪器)、Cyrix以及VIA(威盛)等。在CISC微处理器中，程序的各条指令是按顺序串行执行的，每条指令中的各个操作也是按顺序串行执行的。顺序执行的优点是控制简单，但计算机各部分的利用率不高，执行速度慢。CISC架构的服务器主要以IA-32架构(Intel Architecture,英特尔架构)为主，而且多数为中低档服务器所采用。

如果企业的应用都是基于NT平台的应用，那么服务器的选择基本上就定位于IA架构(CISC架构)的服务器。如果企业的应用主要是基于Linux操作系统，那么服务器的选择也是基于IA结构的服务器。如果应用必须是基于Solaris的，那么服务器只能选择SUN服务器。如果应用基于AIX(IBM的Unix操作系统)的，那么只能选择IBM Unix服务器(RISC架构服务器)。

折叠RISC服务器

RISC的英文全称为"Reduced Instruction Set Computing"，中文即"精简指令集"，它的指令系统相对简单，它只要求硬件执行很有限且最常用的那部分指令，大部分复杂的操作则使用成熟的编译技术，由简单指令合成。在中高档服务器中普遍采用这一指令系统的CPU，特别是高档服务器全都采用RISC指令系统的CPU。在中高档服务器中采用RISC指令的CPU主要有Compaq(康柏，即新惠普)公司的Alpha、HP公司的PA-RISC、IBM公司的Power PC、MIPS公司的MIPS和SUN公司的Sparc。

折叠VLIW服务器

VLIW是英文"Very Long Instruction Word"的缩写，中文意思是"超长指令集架构"，VLIW架构采用了先进的EPIC(清晰并行指令)设计，我们也把这种构架叫做"IA-64架构"。每时钟周期例如IA-64可运行20条指令，而CISC通常只能运行1-3条指令，RISC能运行4条指令，可见VLIW要比CISC和RISC强大的多。VLIW的最大优点是简化了处理器的结构，删除了处理器内部许多复杂的控制电路，这些电路通常是超标量芯片(CISC和RISC)协调并行工作时必须使用的，VLIW的结构简单，也能够使其芯片制造成本降低，价格低廉，能耗少，而且性能也要比超标量芯片高得多。基于这种指令架构的微处理器主要有Intel的IA-64和AMD的x86-64两种。

微服务入门|微服务架构怎么设计

将一个单体应用拆分成一组微小的服务组件，每个微小的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据。

通过以上的定义描述，我们可以基本确定给出微服务的节特征：

用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：

在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：

1、客户端如何访问这些服务？

2、每个服务之间如何进行通信？

3、多个微服务，应如何实现？

4、如果服务出现异常宕机，该如何解决？

以上这些都是问题，需要一个个解决。

在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。

现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：

此时，后台有N个服务，前台就需要记住管理N个服务，一个服务下线、更新、升级，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。

除了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务操作时，往往是跨业务模块进行操作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。

基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：

网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

最终，添加了网关(API Gateway)的业务架构图变更为如下所示：

所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。进程间通信的方案已经比较成熟了，现在最常见的有两大类：同步调用、异步消息调用。

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST和 RPC

基于REST和RPC的特点，我们通常采用的原则为：向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。需要付出的代价是一致性的减弱，需要接受数据最终一致性，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现幂等性，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的 Broker，作为中间代理池。

常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。

最终，大部分的服务间的调用架构实现如下所示：

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。这就出现了新的问题：

这就是服务的发现、识别与管理问题。解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。

具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。当服务下线时，服务管理框架会发送服务下线的通知给其他服务。

常见的服务管理框架有：Zookeeper等框架。

如上的问题解决方案有两种具体的实现，分别是：基于客户端的服务注册与发现、基于服务端的服务注册与发现。

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。

优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：

关于服务器架构设计，服务器架构的介绍到此结束，希望对大家有所帮助。