6.部署架构

部署架构
部署逻辑视图与部署物理视图建议重新画。

部署逻辑视图就是部署节点（数据库服务器、应用服务器节点和接口服务器节点等）；

部署物理视图包括纵、横向边界、内外网、防火墙、网络设备、数据库服务器集群、应用服务器集群等；

用户访问APP、WEB、H5页面通过LBS算法调用到最佳的nginx服务器，nginx通过规则转发调用到指定的服务或服务网关，gatway经过鉴权、风控等安全校验后通过consul注册中心LB路由到指定的业务服务，业务服务根据需要调用对应的数据支持端、RPC服务短信或第三方服务端，完成业务功能后返回对应的数据。

整个部署架构分为入口访问组、核心服务组、基础支撑组和服务监控组。
1、LBS域名指向服务域名，开通https、防ddocs等安全性功能。
2、入口访问组包含nginx、potal web、activity web、gateway服务，nginx需要开通外网流量权限，gateway需打通与核心业务组网段调用，potal web和activity web为前端网页服务，可视情况与nginx服务同机器部署或单独部署。
3、核心服务组根据各服务压测和预估QPS状况，部署相应量级的服务节点，为保障服务高可用，每个服务至少部署两个节点。
4、基础支撑组需开放核心业务组网络相互访问，部署consul注册中心集群，consul集群请独立部署并至少部署3个server节点和2+个client节点，DB至少保证主从节点配置，rabbitmq集群使用镜像模式保障服务的高可用，redis根据服务需要主从、集群部署，其他支持服务根据需要部署相应套件。
5、服务监控组需开放核心业务组网络相互访问，zabbix、prometheus、zipkin server根据服务需要部署相应节点套件，ELK部署至少3个master节点和3个data节点，数据节点建议内存30G，master节点建议10G，聚合节点等根据需要配置，日志类索引根据需要设置n*3个Primaries（如无特殊需要Replicas设置为0），日志索引名称按天存储。日志收集采用filebeat -> kafka -> logstash -> elasticsearch套件，logstash路由pipeline简化配置和服务管理。

部署架构也叫网络架构，就是底层服务器、网路的设计，提供网络安全、服务可靠性的设计。再简单一些理解，就是你这些应用、数据库都放在那台服务器上，这些服务器都在哪个ip端，怎么进行访问。

部署架构：
通过建立不同应用和业务之间的沟通机制，可以把系统中各项独立的部分整合为一个整体，以此来提升企业业务效率，降低业务成本，提高数据精确性及流程的合理性。也正因此，成熟、完美的系统架构部署能力是衡量系统运作能力的重要指标。

部署逻辑视图

部署物理视图

物理架构
物理架构的内容主要包括 IDC 机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单和域名清单。
将这些内容以列表和图形方式整理出来，就会很容易了解和发现问题，只有发现问题才能解决问题，特别是在全局体系架构方面，这也是表和图的价值所在。
当时这家公司共有 5 个地区、8 个机房，虽然只有 200 多台服务器，但分布很散，导致物理结构复杂，通讯也很复杂。技改前故障不断，其主要的一个原因就是物理架构不合理，运维要占 60%、70% 的责任，当时却把责任归咎为应用架构，这是个错误的方向。
物理架构的不合理，应用架构是很难合理的，因为物理架构是我们的基础设施，位于最底层，下层为上层服务，运维要为应用服务，应用要为业务服务，业务要为客人服务。

系统部署拓扑图

部署架构-数智豫电-2022年-概设

部署方式：二级部署。
部署方案：采用微服务部署架构，由两台web应用服务器部分别部署Nginx服务形成Nginx负载。两台后端服务器以双注册中心方式，分别部署4个基础服务和8个基础应用服务，作为平台核心功能块。基础服务包括注册服务、网关服务、鉴权服务、分布式事务服务；基础应用服务包括需求提报服务、搜索服务、用户服务、场景服务、工作流服务、系统服务、评价服务、分析服务。消息服务采用kafka集群方式为系统提供服务。缓存服务、数据库、搜索服务均采用云平台组件，分别为Redis分布式缓存、Mysql集群、云搜索服务CSS。非结构化数据则存储于云平台的OBS对象存储。如下图所示：

部署架构-数智豫电-2022年-概设

逻辑架构和物理架构

架构的分类

对于“架构”来讲，理论上划分了5种架构视图，分别是：逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字，大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下，便于大家理解，大家可以不必纠结概念和这些理论。

• 逻辑架构：逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。
• 开发架构：开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。
• 运行架构：顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。\
• 物理架构：物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。
• 数据架构：数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。

上面讲了那么多，相信国内很少有公司是严格按照这五种视图去分工和设计的。其实在笔者眼中，架构大致分为两种：软件架构、系统架构。前三种视图，可以归纳为软件架构，而后两种架构，则归为系统架构。这也比较符合国内大部分中小型互联网公司的现状。
根据应用特性的不同，关注侧重点可能不同。例如，某些门户类的互联网应用，读多写少而且业务相对比较简单，则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用，例如电商类大规模交易型的应用，对每个层面和每个环节都会比较关注。对于业务型的系统，例如一些生产型企业使用的ERP，或者仅供企业内部使用的一些MIS、OA应用，通常更关注功能和复杂的业务和实现和扩展，而对性能等方面又可能不要太高，这类应用则更关注纯软件架构层面。这里，不展开做具体讨论。所以很多时候，架构师也需要是一个团队，而不是一个人“全栈”。

架构设计到底是什么

在长期的技术招聘面试中，我发现在很多人眼中，架构就是分层，架构设计就是“三层架构”（或者四层、五层…反正分层越多就说明项目越复杂而且架构就越牛），或许是受到诸如PetShop之类的示例项目的影响，这里暂时不去追究原因了。
之前已经纠正过很多人的误解-架构不只是软件架构。说一下通俗点的理解：
软件架构就是实用而且优雅的设计，它不在于分多少层，或者应用了多少种设计模式/架构模式等。它应该是以满足实现用户需求为前提，以开发人员普遍可接受为根本的，而且要符合系统特性和业务发展需要的，从软件设计的角度，能够达到层次清晰、可维护、可重用、可扩展…就非常优秀了，无需刻意去纠结分了多少层，是否使用了什么模式，有多么抽象等。以面向对象设计为例，基本目标是“高内聚、低耦合”，为此我们可能会遵循一些常见的设计原则（例如经典的SOLID设计原则）。最后纠正一点，通常我们所说的模式，其实又分为很多种，并不是仅仅指的是“设计模式”（设计模式也有千千万，并不是只有常见的GOF 23种设计模式）。通常包括：企业架构模式、设计模式、SOA模式、企业集成模式等等。
强调一下，架构要讲求“实用”，而且开发人员普遍可接受，要符合现状的。否则，再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套和过度设计只会让项目“流产”。

关于Tier和Layer

笔者曾多次在一些技术社区和论坛看到一些关于Tier和Layer的争论，众说纷纭。其实最容易被广泛认可和接受的理解就是：Tier通常指的是物理上的分层，由执行同样功能的一台（或者一组）服务器定义。而Layer通常指的是逻辑上的分层，对于代码的组织，例如：我们通常提到的“业务逻辑层，表现层，数据访问层”等等。
Tier指代码运行的位置，多个Layer可以运行在同一个Tier上的，不同的Layer也可以运行在不同的Tier上，当然，前提是应用程序本身支持这种架构。以J2EE和.NET平台为例，大多数时候，不同的Layer之间都是直接通过DLL或者JAR包引用来完成调用的（例如：业务逻辑层需要引用数据访问层），这样部署的时候，也只能将多个Layer同时部署在一台服务器上。相反，不同的Layer之间如果是通过RPC的方式来实现通信调用的，部署的时候，便可以将不同的Layer部署在不同的服务器上面，这也是很常见的解耦设计。
如下图所示：

顺便再纠正一点，很多人问“到底什么是web服务器，什么是应用服务器”。这个恐怕没有标准答案的。有些人可能觉得，处理静态资源的就是web服务器，处理动态请求的就是应用服务器，这其实是不准确的。以互联网领域典型的SOA架构为例，上层Web应用所在的服务器，可以叫web服务器，web应用仅仅负责处理输入/输出，而提供服务宿主的服务器可以称为应用服务器（也包含对业务逻辑和数据访问的处理）。当然，服务的宿主方式可以有很多中，可以是系统服务，是可执行程序，是web应用，是Socket网络服务…

逻辑分层和物理分层的好处

逻辑分层的好处：

1. 代码组织更清晰
2. 更易于维护
3. 更好的代码重用性
4. 更好的团队开发体验性
5. 更高的代码清晰度

物理分层的好处：

1. 性能
2. 可伸缩性
3. 容错性
4. 安全性

• 架构师的分类

  
  架构师往往是很多开发人员向往的职业，也不是像很多人想象中的那样（画一下PPT或者UML草图，然后交给程序员们去实现，然后自己就自由玩耍了）。国内很多公司，是没有架构师这种岗位定义的，通常是由技术优秀和经验比较丰富的开发人员担任，身兼多职的情况也并不少见（我见过很多小公司的骨干人员是身兼技术主管、系统分析师、项目经理、架构师、核心开发人员…）。值得纠正的就是，架构师和系统分析师不同，系统分析师更侧重在项目早期的需求分析。而架构师，一般贯穿整个软件开发周期，与项目经理也是相辅相成的。微软对于架构师，又分为：软件架构师、系统架构师、解决方案架构师、企业架构师等。而其它一些厂商，可能又会划分:技术架构师、业务架构师、网络架构师、安全架构师、SOA架构师……
  大家不必对这些概念太纠结。按照笔者的理解，国内大互联网公司里，架构师一般只会分2-3个方向：软件架构师和系统架构师（有些企业叫运维架构师），有些企业对于比较资深DBA而且懂整个系统架构的，还会分出所谓的“数据架构师”。至于具体Title，大可不必纠结，只需了解自己的兴趣，知晓了大致发展和定位，然后朝该方向努力即可。对于程序员而言，最基本的还是先写出高质量的代码，在实战中逐步提升自己设计思维。
  
  限于笔者水平和理解有限，文中全部文字和描述等全凭笔者记忆和理解写出，难免出现错误，请热心的读者及时批评和指正。
  由于时间有限，部分图片笔者画的比较粗糙，也请读者谅解。