BIM是源自于“Building Information Modeling”的缩写，中文译为“建筑信息模型”。该技术通过数字化手段，在计算机中建立出一个虚拟建筑，该虚拟建筑会提供一个单一、完整、包含逻辑关系的建筑信息库。需要注意的是，在这其中“信息”的内涵不仅仅是几何形状描述的视觉信息，还包含大量的非几何信息，如材料的耐火等级和传热系数、构件的造价和采购信息等等。其本质是一个按照建筑直观物理形态构建的数据库，其中记录了各阶段的所有数据信息。建筑信息模型（BIM）应用的精髓在于这些数据能贯穿项目的整个寿命期，对项目的建造及后期的运营管理持续发挥作用。 BIM基本特性 BIM是以建筑工程项目的各项相关信息数据为基础而建立的建筑模型。通过数字信息仿真，模拟建筑物所具有的真实信息。BIM是以从设计、施工到运营协调、项目信息为基础而构建的集成流程，它具有可视化、协调性、模拟性、优化性和可出图性5大特点。建筑公司通过使用BIM，可以在整个流程中将统一的信息创新、设计和绘制出项目，还可以通过真实性模拟和建筑可视化来更好地沟通，以便让项目各方了解工期、现场实时情况、成本和环境影响等项目基本信息。 (一) 可视化 可视化，即“所见即所得”的形式，对于建筑行业来说，可视化真正运用在建筑业地作用非常大。例如，经常拿到的施工图纸只是各个构件的信息，在图纸上以线条绘制表达，但是真正的构造形式就需要建筑业人员去自行想象了。如果建筑结构简单，那么没有太大的问题，但是近几年形式各异、复杂造型的建筑不断推出，那么光靠想象就不太实际了。所以BIM提供了可视化的思路，将以往的线条式的构件，形成一种三维的立体实物图形展示在人们的面前。 以前，建筑业也会制作设计方面的效果图，但是这种效果图是分包给专业的效果图制作团队，根据线条式信息识读设计制作出来的，并不是通过构件的信息自动生成的，因此缺少了同构件之间的互动性和反馈性。而BIM提到的可视化，则是一种能够同构件之间形成互动性和反馈性的可视化。在BIM建筑信息模型中，由于整个过程都是可视的，所以可以用于效果图的展示和报表的生成。更重要的是通过建筑可视化，可以在项目的设计、建造和运营过程中进行沟通、讨论和决策。 (二) 协调性 协调性是建筑业中的重点内容，无论是施工单位和设计单位还是业主，都在做着协调及相互配合的工作。一旦在项目的实施过程中遇到了问题，就需要各相关人员组织起来进行协调会议，找出施工中问题发生的原因及解决办法，然后做出相应变更、补救措施等来解决问题。那么，问题的协调就只能等出现问题后再进行协调吗?在设计时，由于各专业设计师之间的沟通不到位，往往会出现各种专业之间的碰撞问题，例如，在对暖通(供热、供燃气、通风及空调工程)等专业中的管道进行布置时，可能遇到构件阻碍管线的布置。这种问题是施工中常遇到的碰撞问题，而BIM的协调性服务，可以帮助处理这种问题，也就是说BIM建筑信息模型可在建筑物建造前期，对各专业的碰撞问题进行协调，生成并提供出协调数据。当然，BIM的协调作用也不止应用于解决各专业间的碰撞问题，它还可以解决电梯井布置与其他设计布置及净空要求的协调、防火分区与其他设计布置的协调以及地下排水布置与其他设计布置的协调等问题。 (三) 模拟性 BIM的模拟性并不是只能模拟、设计出建筑物的模型，还可以模拟难以在真实世界中进行操作的事件。在设计阶段，BIM可以对设计上需要进行模拟的一些事件进行模拟实验，例如，节能模拟、紧急疏散模拟、日照模拟和热能传导模拟等。在招投标和施工阶段可以进行4D模拟(3D模型加项目的发展时间)，也就是根据施工的组织设计模拟实际施工，从而确定合理的施工方案。同时还可以进行5D模拟(基于3D模型的造价控制)，从而实现成本控制。在后期运营阶段，还可以进行日常紧急情况处理方式的模拟，如地震人员逃生模拟和消防人员疏散模拟等。 (四) 优化性 事实上，整个设计、施工和运营的过程就是一个不断优化的过程，在BIM的基础上，可以更好地进行优化。优化通常受信息、复杂程度和时间的制约。准确的信息影响优化的最终结果，BIM模型提供了建筑物的实际存在的信息，包括几何信息、物理信息以及规则信息。对于高度复杂的项目，由于参与人员本身的原因，往往无法掌握所有的信息，因此需要借助一定的科学技术和设备的帮助。现代建筑物的复杂程度大多超过参与人员本身的能力极限，BIM及与其配套的各种优化工具提供了对复杂项目进行优化的服务。 基于BIM的优化，可以完成以下两种任务： 第1种：对项目方案的优化。把项目设计和投资回报分析结合起来，可以实时计算出设计变化对投资回报的影响。这样业主对设计方案的选择就不会停留在对形状的评价上，而是哪种项目设计方案更有利于自身的需求。 第2种：对特殊项目的设计优化。在大空间随处可看到异型设计，如裙楼、幕墙和屋顶等。这些内容看似占整个建筑的比例不大，但是占投资和工作量的比例却往往很大，而且通常是施工难度较大和施工问题较多的地方，对这些内容的设计施工方案进行优化，可以显著地改善工期和造价。 (五) 可出图性 使用BIM绘制的图纸，不同于建筑设计院所设计的图纸或者一些构件加工的图纸，而是通过对建筑物进行可视化展示、协调、模拟和优化以后，绘制出的综合管线图（经过碰撞检查和设计修改，消除了相应错误）、综合结构留洞图（预埋套管图）以及碰撞检查侦错报告和建议改进方案。 BIM与工程造价的交流 （一）BIM对造价的影响 BIM对于造价来说很有可能会改变造价的整个工作流程，包括造价员的整个工作思维模式，传统的造价工作模式是：识图→算量（目前是软件提量+手工算量）→套项→调整材料价、调整取费，完成造价。这样一个过程有很多重复的工作，并且很多环节是需要大量的人工劳动力来解决造价中遇到的复杂问题，在可研、设计、招标、施工阶段需要重复计算不同阶段的造价。这样的工作模式势必会增加很多额外的成本，尤其后期设计中的变更修改阶段，每一次修改都需要重新核对一下图纸的改变程度，在传统的单机单专业的工作方式，很多设计修改不会被造价人员做发现，这样的造价计算肯定会和实际的清单会有很多误差。而基于BIM下的造价可以在不同阶段计算不同阶段的造价清单，只要模型建立的足够精细就可以得到十分精准的造价信息。 工程造价分为三个部分，算量问题，组价问题和合同问题。现阶段来看，BIM技术的普及对工程造价的冲击主要局限于算量问题上。BIM作为应用软件，更加简化了工程量的计算，使造价师从算量的繁琐工作中脱离出来，大量减少了计算工作，将更多的目光放在组价和合同问题上。 另外BIM技术使各阶段数据无缝对接，实现全过程、全要素可靠、准确地工程造价管理。这在一定程度上打破了之前由于各阶段数据不连续，各环节之间协同共享存在障碍，导致工程信息不透明，致使工程项目”水深“现象。 (二) BIM是否会取代造价 前面提到，BIM的普及，会让造价师的目光更多的集中在组价和合同问题上。对于价格，合同，建设工程前后的费用控制，相关法律和规章是以工程经验积累起来的。技术软件再万能，在没有标准可循的组价、合同法律法规的理解等方面也不能和人脑比拼。当工程量不需要计算的时候，造价师会更有精力去做成本控制等一些控制造价的核心内容。所以BIM只能技术给造价师提供更宽、更高的职业空间。 在国外，工料测量师被业主称为“费用经理”。他们的业务不止于单一环节的“计价”、“造价”，更在于全过程“控价”。从工程量预测，到投标招标决策；从工程可行性判断，到工程成本管理，工料测量师都可以从经济角度予以解决方案。反观国内造价师，“造价”二字当顶，已经明示其本职。目前国内造价师的工作也确实以算量、套价为主，很少实现全过程成本管控。 所以未来造价工程师的咨询业务很可能会改变，不再是单一的造价内容，而是关注于工程项目全过程的成本管控咨询。但是BIM业务也不会完全取代造价业务，原因如下： BIM即便发展到人工智能的程度，始终不如人懂得其他人的“心理活动”，对敏感性问题完全无能。 建设工程是为人服务的。人有种种立场和差异化感受。用户与用户之间，企业与企业之间，社会与社会之间，甚至这三者之间，追求往往不那么一致。用户体验、造价规范与工程效益的同步协调，涉及种种微妙的利害权衡。国内的工程造价，不仅是经济账，也是心理战。 更实时更适配的BIM算法始终依赖人的输入。BIM计算实质是工程经验的数据化，但实际的工程实践不是BIM模型所能实现的。所以工程经验数据化的进度和精度取决于人对工程的理解。

转载本文需注明出处：微信公众号EAWorld，违者必究。 引言： 在企业级应用实施和运营过程中，为了解决企业中部分业务场景访问量大、并发量高的问题，就需要对系统架构及应用参数做出优化和调整，如架构优化、数据库优化、应用优化等。 应用系统部署优化是一个不断尝试、实践、总结的过程，并针对不同企业的特点制定相关解决方案。通过应用系统架构、数据库及应用优化入手，并通过相关案例加以说明和解释。 目录： 1、应用系统架构简介 2、数据库及应用优化方案 3、优化案例分析 1. 应用系统架构简介 应用系统架构的发展 当今互联网技术发展日新月异，应用系统架构也在不断的更新迭代，从传统的单一架构演变为如今的集群架构、分布式、微服务架构等，以便满足用户对系统的要求。 NO1.单机部署架构 互联网建设初期，用户访问量有限，数据量不大，多数系统采用单台服务器部署应用服务，系统服务、文件、数据库等所有系统资源部署在一台服务器上. NO2.应用和数据分离 随着用户量和数据量的不断攀升，业务对系统的性能要求越来越高，这是需要将应用和数据分离，单独部署相关的业务组件。 NO3.引入NoSQL数据库架构 随着用户不断的增加，关系型数据库压力变大，访问延迟，性能下降，这时加入缓存技术，将查询较多数据缓存起来，以加快应用访问速度。 NO4.应用集群部署 在访问量高峰时期，单一的系统服务往往无法承受巨大的访问量，这时就需要做集群服务，以减少单台服务器的压力。 中小企业应用系统多数为集群部署，既保证系统的稳定性，又能降低因服务器故障，造成数据丢失的风险。 其他在应用集群部署方案上演变的架构系统，如：分布式、微服务架构等，对系统稳定性和安全性做的更加出色。 2.数据库及应用优化方案 本章节主要介绍mysql数据库的部署及常见优化方案；应用以tomcat为例，简单介绍tomcat的常见参数优化配置。 数据库分类介绍 当今的互联网企业中，最常用的数据库模式主要有两种，即关系型数据库和非关系型数据库。 关系型数据库：采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，行和列被称为表，一组表组成了数据库。 MySQL：甲骨文旗下产品，体积小、速度快、成本低，代码开源，适用于中小型网站开发 ORACLE：同样为甲骨文旗下产品，Oracle可移植性好、使用方便、功能强，高效率、可靠性好的、适应高吞吐量的数据库方案 SQLServer：微软旗下产品，图像化用户界面，使用方便、web技术支持良好、丰富的编程接口 非关系型数据库：去掉关系数据库的关系型特性，数据之间无关系，非常容易扩展。同时也在架构的层面上带来了可扩展能力。大数据量，高性能，NoSQL数据库具有非常高的读写性能。 Redis：基于内存亦可持久化的日志型、Key-Value数据库 MongoDB：分布式文件存储数据库，高效的二进制数据存储，使用方便 HBASE：列存储数据库，以列簇式存储，将同一列数据存在一起 MySQL数据库部署 案例系统环境为RadHat_6.6_64；数据库版本为MySQL-5.7.23社区版(mysql-5.7.23-1.el6.x86_64.rpm-bundle.tar)。 mysql安装方法有RPM包安装和源码包安装，RPM安装是最简单的安装方法，不需要源码编译适合初学者安装使用。 1.检查系统是否含有自带mysql 使用命令# rpm -qa|grep -i mysql 2.yum卸载自带mysql 使用命令# yum -y remove mysql-libs-* 卸载完成后，请再次执行步骤1进行检查 3.上传mysql-5.7.23-1.el6.x86_64.rpm-bundle.tar到服务器，并解压缩 # tar –xvf mysql-5.7.23-1.el6.x86_64.rpm-bundle.tar 4.rpm安装mysql数据库，按照顺序以下命令执行 #rpm -ivh mysql-community-common-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-libs-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-libs-compat-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-embedded-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-devel-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-embedded-devel-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-client-5.7.23-1.el6.x86_64.rpm #rpm -ivh mysql-community-server-5.7.23-1.el6.x86_64.rpm 5.初始化数据库 # mysqld --initialize 6.启动数据库并修改root默认密码 使用命令 # service mysqld start --启动数据库 使用命令 # service mysqld status --检查数据库状态 使用命令 # cat /var/log/mysqld.log --查看数据库root初始化密码 登录mysql数据库： # mysql -uroot –p ‘!w1wzCxJprmv’ 设置root用户的新密码： #set password=password('******'); 可设置mysql服务开机自启动： chkconfig --add mysqld chkconfig mysqld on 检查：chkconfig --list mysqld MySQL参数优化 需要修改my.cnf配置文件，修改完成后，重新启动mysql # service mysqld restart 参数设置： skip-name-resolve #开启该选项，则所有远程主机连接授权都要使用IP地址方式 back_log = 512 #系统在一个短时间内有很多连接，则需要增大该值，该值指定到来的TCP/IP连接的侦听队列的大小，Linux系统推荐设置为小于512的整数 max_allowed_packet = 4M #限制插入的数据包大小 max_connections = 500 #指定MySQL允许的最大连接进程数 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER # NO_ENGIN_SUBSTITUTION 在创建表指定一个不存在的存储引擎，mysql会提示错误，反之，则会设置成默认的innodb # STRICT_TRANS_TABLES 在插入或更新数据时进行更严格的检查，如果发现某个值缺失或非法，MySQL将抛出错误，语句会停止运行并回滚 # NO_AUTO_CREATE_USER 新建用户不能空密码 lower_case_table_names=1 #“0”是表名存储是给定的大小写，比较是区分大小写的 “1”表名存储在磁盘是小写，比较是不区分大小写的 “2”表名存储是给定的大小写，比较是小写 explicit_defaults_for_timestamp=true #如果一行数据中某些列被更新了，如果这一行中有timestamp类型的列，那么这个timestamp列的数据也会被自动更新到，更新操作所发生的那个时间点 skip-networking #开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！！！！！ MySQL不同访问量级时的架构应用 日访问量为万级以内 无需做架构层优化，应用和数据库分离部署，但是考虑数据的安全和备份，可以考虑搭建主从部署，主数据库承担所有业务访问，从数据库用作热备 日访问量达到十万以上 可以考虑一主多从（读写分离）架构，即主数据库承担“写”任务，从数据库承担“读”任务 日访问量达到百万以上 一主已经无法承担相关业务访问，需要进一步作出调整。我们将相关的用户、业务、权限等分离出来，单独运行至一个数据库，然后再做主从，即分库；也可以将读取量或者写入量大的表分离出来，单独运行至一个数据库，或者将大表分离成多个小表，即分表。这种方式就是分库分表的模式 主从同步架构介绍 可用于用户量较小，允许短时终止服务的子系统或小型系统。 当master出现故障时，可以通过手动调整web应用服务器连接数据库的地址，将数据库请求切换到slave数据库中。 当master故障修复后，可以将slave数据库的整个mysql-data目录拷贝至master中，值得注意的是，mysql-data目录中包含auto.cnf文件，这是mysql的server-uuid值，需要继续使用master中原有的值，然后重新配置主从同步。 [auto] server-uuid=a34c331b-e55c-11e9-9107-000c292efb70 也可以将Slave用作主库使用，Master当作从库使用，重新配置主从同步。 主从同步部署 1.主库创建同步用户 mysql>GRANT REPLICATION SLAVE,FILE ON *.* TO 'replication'@'%' IDENTIFIED BY '*******' 2.修改主库配置文件 编辑my.cnf文件 log-bin=mysql-bin #日志文件名 server-id=1 #主数据库端ID号 修改问完成，请重启 3.查询主库master状态 mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 154 | | | +------------------+----------+--------------+------------------+ 调整完毕后不要再操作主库，防止主库数据发生变化 4.从库执行同步命令 mysql>change master to master_host=‘192.168.0.1’,master_user= ‘replication ’,master_password=‘******',master_log_file='mysql-bin.000001',master_log_pos=154; mysql>start slave; #开启同步 5.检查从库同步状态 show slave status\G; # Slave_IO_Running及Slave_SQL_Running进程必须正常运行 主从同步参数优化 主从同步参数优化，修改my.cnf文件 1.参数进行忽略（从库配置文件） 当业务中出现无需同步的数据表时，可以选择replicate_wild_ignore_table=db.table参数进行忽略（从库配置文件） 2.跳过指定错误（从库配置文件） slave-skip-errors = 1062，1053 #根据业务类型选择 1007：数据库已存在，创建数据库失败 1008：数据库不存在，删除数据库失败 1050：数据表已存在，创建数据表失败 1051：数据表不存在，删除数据表失败 1054：字段不存在，或程序文件跟数据库有冲突 1060：字段重复，导致无法插入 1061：重复键名 1068：定义了多个主键 1094：位置线程ID 1146：数据表缺失，请恢复数据库 1053：复制过程中主服务器宕机 1062：主键冲突 3.删除同步日志（主库配置文件） Master库中的同步日志需要及时删除 Expire_logs_days = 7 #删除7天前的同步日志 主从复制原理简介 slave库手动执行change master to 语句连接master库，提供了连接的用户一切条件（user 、pwd、port、ip），并且让slave知道，二进制日志的起点位置（file名 position 号），同时开启start slave slave库的IO线程和主库的dump线程建立连接 slave库根据change master to 语句提供的file名和position号，IO线程向主库发起binlog的请求 master库dump线程根据从库的请求，将本地binlog发给slave库IO线程 slave库IO线程接收binlog并存放到本地relay-log中 slave库SQL线程应用relay-log，默认情况下，已经应用过的relay-log 会自动被清理 主主同步架构介绍 由于keepalived会检测mysql运行状态，在重启mysql时注意，先停止keepalived服务，确认mysql运行正常时，再启动keepalived。 主主配置方式和上文介绍的主从配置类似，即master复制slave数据，slave复制master数据。 Keepalived实现自动切换 Keepalived是实现集群高可用的服务软件，通过虚拟路由冗余协议（vrrp），将N台提供相同服务的路由组成一个路由组，可以有一个master和多个backup，master上是对外提供服务的虚拟ip，当backup收不到master发送的vrrp包时就认为master宕掉，此时选举一个backup来充当master并重新绑定虚拟ip，来保证服务高可用性。 1.用户自行下载相关版本并安装 # cd keepalived # ./configure --prefix=/usr/local/keepalived （安装路径） # make && make install 2.设置系统为系统服务方便启动停止 mkdir /etc/keepalived cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/ cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/ cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/ ln -s /usr/local/sbin/keepalived /usr/sbin/ ln -s /usr/local/keepalived/sbin/keepalived /sbin/ 3.建议将keepalived设置为自启服务 chkconfig keepalived on 4.Keepalived配置管理 修改/etc/keepalived/keepalived.conf文件 5.编写keepalived执行脚本 注意：授权chmod +x /etc/keepalived/mysql_check.sh 6.可配置邮件发送提醒 编写sendmail.pl脚本，注意：授权chmod +x /etc/keepalived/sendmail.pl 7.keepalived配置文件 global_defs { #全局配置 notification_email { #定义报警邮件地址 root@localhost } notification_email_from root@localhost #定义发送邮件的地址 smtp_server 127.0.0.1 #邮箱服务器 smtp_connect_timeout 30 #定义超时时间 router_id LVS_DEVEL #定义路由标识信息，建议使用主机名 } vrrp_script chk_mysql { script "/etc/keepalived/mysql_check.sh" interval 2 weight -20 } vrrp_instance VI_83 { #定义实例 state MASTER #状态参数 master/backup 只是说明 interface eth0 #虚ip绑定网卡位置 virtual_router_id 83 #同一个集群id一致 priority 100 #priority值最大的将成为master mcast_src_ip 192.168.0.1 #发送组播包的地址，不设置则使用网卡默认ip advert_int 1 #主备通讯间隔s authentication { #设置认证 auth_type PASS auth_pass 1111 } track_script { chk_mysql } virtual_ipaddress { #虚拟ip 192.168.0.0 } notify_master /etc/keepalived/sendmail.pl #邮件发送脚本 } 一主多从架构部署介绍 应用服务器只配置mycat地址即可，mycat可以实现读写分离和故障切换。 Master负责写入，Slave负责读取，同时MySQL可以支持级联同步部署。 MySQL为保证事务的完整性，复制在slave上是串行化的，也就是多个master上的并行更新操作不能在同一slave上同时进行。 Mycat读写分离配置及优化 mycat可用于读写分离和数据切分的高可用中间件，并支持基于心跳检测的自动故障切换,mycat主要包含两个核心配置文件server.xml和schema.xml 1.server.xml配置优化 <user name=“user”> <!—对客户端提供的用户名、密码 及表空间--> <property name="password">******</property> <property name="schemas">testdb</property> <property name="readOnly">false</property> <!--readOnly设置成false，代表可进行读写操作--> </user> 2. schema.xml配置优化 <schema name=“testdb" checkSQLschema="false" sqlMaxLimit="100" dataNode=“dn1"> </schema> <dataNode name=“dn1" dataHost="host001" database=“db1" /> <dataHost name=" host001" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="2" slaveThreshold="100"> <heartbeat>show slave status </heartbeat> <writeHost host=“mysql-1” url=“192.168.0.1:3306” user=“user” password=“******”> <!—master可读、写操作，slave只读--> <readHost host="mysql-1" url="192.168.0.1:3306" user=“user" password="******" /> <readHost host="mysql-2" url="192.168.0.2:3306" user=“user" password="******" /> </writeHost> <writeHost host=“mysql-2” url=“192.168.0.2:3306” user=“user”password=“******”> <!—master故障，切换slave读写--> <readHost host="mysql-2" url="192.168.0.2:3306" user=“user" password="******" /> </writeHost> </dataHost> 参数说明： writeType属性负载均衡类型，目前的取值有3种： writeType="0", 所有写操作发送到配置的第一个writeHost，第一个挂了切到还生存的第二个writeHost，重新启动后以切换后的为准，切换记录在配置文件中:dnindex.properties. writeType="1"，所有写操作都随机的发送到配置的writeHost，1.5以后废弃不推荐。 writeType="2"，不执行写操作 switchType指的是切换的模式，目前的取值也有4种： switchType='-1' 表示不自动切换 switchType='1' 默认值，表示自动切换 switchType='2' 基于MySQL主从同步的状态决定是否切换,心跳语句为 show slave status switchType='3'基于MySQL galary cluster的切换机制（适合集群）（1.4.1），心跳语句为 show status like 'wsrep%' 负载均衡类型，目前的取值有4种： balance="0", 不开启读写分离机制，所有读操作都发送到当前可用的writeHost上。 balance="1"，所有读操作都随机的发送到readHost。全部的readHost与stand by writeHost参与select语句的负载均衡，简单的说，当双主双从模式(M1->S1，M2->S2，并且M1与 M2互为主备)，正常情况下，M2,S1,S2都参与select语句的负载均衡。 balance="2"，所有读操作都随机的在writeHost、readhost上分发。 balance="3"，所有读请求随机的分发到wiriterHost对应的readhost执行，writerHost不负担读压力 Tomcat优化分享 1.内存优化 内存优化主要是对启动参数优化，启动脚本 catalina.sh 中设置 java_OPTS 参数 JAVA_OPTS参数说明： -server 启用jdk 的 server 版 -Xms java虚拟机初始化时的最小内存 -Xmx java虚拟机可使用的最大内存 -XX: PermSize 内存永久保留区域 -XX:MaxPermSize 内存最大永久保留区域 配置示例： JAVA_OPTS=’-Xms1024m -Xmx2048m -XX: PermSize=256M -XX:MaxNewSize=256m -XX:MaxPermSize=256m’ 说明：其内存的配置需要根据服务器（或虚拟机）的实际内存来配置；重启tomcat生效。 2.线程优化 修改server.xml配置文件： maxThreads = “500” //最大线程数，默认200，没有最理想的值，需要不断调整、优化，道道最合理的配置 //当系统需要大量计算时，响应时间取决于cup运算能力，此时maxThreads尽量设小，降低同一时间内争抢cup的线程数 //当系统主要是I/O或操作数据库时，响应时间取决于外部资源等待，此时maxThreads尽量设大，提高同时处理请求的个数 minSpareThreads=“50“ //初始化时创建的线程数，默认值为4 maxSpareThreads="500“ //一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程 acceptCount=“500” //当所有处理的线程都正在使用时，在队列中排队请求的最大数目，默认值为10， //超出队列数，任何请求都会被拒绝一般设置跟maxThreads一样大， //这个值应该是主要根据应用的访问峰值与平均值来权衡配置的 3.其他常用优化 maxPostSize=“-1” //POST请求数据大小限制，默认2M，tomcat-7.0.63之前设置为”0”表示不限制，7.0.63版本之后，设置为负数，表示不显示 connectionTimeout=“20000” //设置连接超时时间毫秒值 maxHttpHeaderSize=“8192” //HTTP请求和响应头的最大量，以字节为单位，默认值为4096字节 URIEncoding=“UTF-8“ //Tomcat中配置URIEncoding=”UTF-8”来进行中文的处理 enableLookups=“false” //如果为true，则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址，为了提高处理能力，应设置为 false 3.优化案例分析 上面章节介绍了架构演变、数据库及相关组件部署优化、Tomcat应用优化等内容，本章节以实际架构案例分析，讲解上述内容在实际架构中的应用。 案例架构采用典型的分层服务架构（三层），即接入层、应用层和数据层，所有应用服务均使用集群部署，保证服务的高可用性。 数据层： 案例系统中，数据读取业务偏多，故考虑使用使用mycat做读写分离，两台数据库同时对外提供读取业务，其中一台主服务器提供写入操作，当master节点宕机之后，mycat组件检测到服务状态，并将读写能力全部切换至slave节点，保证系统的运行 Mycat组件进行读写分离和故障切换，所有应用服务连接keepalived对外提供的虚拟ip进行数据库操作，Mycat本身也是一个高可用集群架构。 应用层： 内网负责均衡服务除了可以负载业务的请求之外，还将DMZ区与内网隔离，避免代理服务器直接请求内网应用，负载均衡Nginx使用时，应当根据集群中服务器的性能、部署服务等，合理进行权重分配。 公共组件应用服务器将组件服务通过分布式系统发布，供其他业务系统使用；也可为移动端提供公共服务组件。 应用集群服务器可能存在文件上传业务，当文件上传至服务器后，注意集群之间的数据同步问题。 接入层： DMZ区：为了解决外部网络不能访问内部网络服务器的问题，而设立的一个非安全系统与安全系统之间的缓冲区。由于DMZ区的特殊性，与Internet相比，DMZ可以提供更高的安全性，但是其安全性比内部网络低，所以在部署时，特别注意网络上的连通性关系。 DMZ区左侧代理服务器主要负责代理推送和设备管理服务对互联网的请求，用户也可直接通过互联网访问到该代理集群服务器，可以用作内部自建应用市场等互联网服务；DMZ区右侧代理服务器主要通过安全网关通道将业务请求代理至内网，安全网关只对其白名单中的服务器和端口进行开放。 *1.注意图中①②③④标注位置的网络开通 *2.图中使用keepalived做高可用架构的地方如图中的⑤标注位置，需要注意虚拟ip的使用 应用部署和优化的方法多种多样，其本身就是一个不断尝试、实践、总结的过程，很多相关的技术方案和阅读资料只能用作借鉴参考，我们需要针对不同企业的特点来制定相关方案，不断去优化尝试，才能最终解决问题。 关于作者：冬火，现任普元移动团队开发运维工程师，主攻Java Web开发、系统架构设计和维护，先后参与多家金融机构移动平台系统的开发和架构设计运维工作。专注服务部署和优化、网络技术爱好者，移动平台架构的践行者。 关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。

技术最终为业务服务，没必要一定要追求先进性，各个企业应根据自己的实际情况去选择自己的技术路径。 它不一定具有通用性，但从一定程度讲，这个架构可能比BAT的架构更适应大多数企业的情况，毕竟，大多数企业，数据没到那个份上，也不可能完全自研，商业和开源的结合可能更好一点，权当抛砖引玉。 大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。 具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。 什么样的大数据平台架构，才是最适合你的？ 何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。 同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。 数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。 数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。 数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习等。 数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。 数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。 数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。 1、数据采集层，这是基础。 离线批量采集，采用的是HADOOP，这个已经成为当前流线采集的主流引擎了，基于这个平台，需要部署数据采集应用或工具。 诸如BAT都是自己研发的产品，一般企业，可以采用商用版本，现在这类选择很多，比如华为BDI等等，很多企业技术实力有，但起步的时候往往对于应用场景的理解比较弱，细节做工很差，导致做出来的产品难以达到要求，比如缺乏统计功能等，跟BAT差距很大，传统企业去采购这类产品，要谨慎小心。 一个建议是，当采购产品的时候，除了技术先进性和指标外，更多的应该问问是版本啥时候上线的，是否在哪里成功部署，是否有足够多的客户，如果能做个测试就更好，否则，你就是小白鼠哦，这个坑踩了不少。 能做和做成产品是两个境界的事情，小的互联网企业当然也能做出对于自己好用的采集工具，但它很难抽象并打造出一个真正的产品，BAT自研其实形成了巨大的优势。 实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。 除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。 爬虫当前也逐渐成为很多企业的采集标配，因为互联网新增数据主要靠它，可以通过网页的解析获取大量的上网信息，什么舆情分析、网站排名啥的，建议每个企业都应该建立企业级的爬虫中心，如果它未在你的大数据平台规划内，可以考虑一下，能拿的数据都不拿，就没什么好说了。 企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。 总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求： 多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集(使用flume、消息队列、OGG等技术)和批量数据分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于传统ETL性能有量级上的提升，这是根本。 可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低采集难度，每配置一个数据接口耗时很短，以降低人工成本。 统一调度管控能力：实现采集任务的统一调度，可支持Hadoop的多种技术组件(如 MapReduce、Spark 、HIVE)、关系型数据库存储过程、 shell脚本等，支持多种调度策略(时间/接口通知/手工)。 2、数据处理层，现在有个词叫混搭，的确是这样。 Hadoop的HIVE是传统数据仓库的一种分布式替代。应用在传统ETL中的数据的清洗、过滤、转化及直接汇总等场景很适合，数据量越大，它的性价比越高。但目前为止看，其支撑的数据分析场景也是有限的， 简单的离线的海量分析计算是它所擅长的，相对应的，复杂的关联交叉运算其速度很慢。 一定程度讲，比如企业客户统一视图宽表用HIVE做比较低效，因为涉及到多方数据的整合，但不是不可以做，最多慢点嘛，还是要讲究个平衡。 hadoop到了X000台集群的规模也撑不住了,当前很多企业的数据量应该会超过这个数量，除了像阿里等自身有研发能力的企业(比如ODPS)，是否也要走向按照业务拆分Hadoop集群的道路?诸如浙江移动已经拆分了固网、移网、创新等多个hadoop集群。 Hadoop的SPARK的很适合机器学习的迭代，但能否大规模的应用于数据关联分析，能否一定程度替代MPP，还需要实践来验证。 MPP应该来说，是采用分布式架构对于传统数据仓库最好的替代，毕竟其实际上是变了种的关系型数据库，对于SQL提供完整支持，在HIVE做了转化分析后，数据仓库的融合建模用它来做性能绰绰有余，其性价比较传统DB2更好一点，比如经过实用，Gbase30-40台集群就能超过2台顶配的IBM 780。 MPP现在产品很多，很难做优劣判断，但一些实践结果可以说下，GBASE不错，公司很多系统已经在上面跑了，主要还是国产的，技术服务保障相对靠谱，ASTER还有待观望，自带一些算法库是有其一些优势，GreenPlum、Vertica没用过，不好说。 大数据平台的三驾马车，少不了流处理。 对于很多企业来讲，其显然是核武器般的存在，大量的应用场景需要它，因此务必要进行建设，比如在IOE时代不可想象的实时、准实时数据仓库场景，在流处理那里就变得很简单了，以前统计个实时指标，也是很痛苦的事情，当前比如反欺诈实时系统，一天系统就申请部署好了。 只尝试过STORM和IBM STREAM，推荐IBM STREAM，虽然是商业版本，但其处理能力超过STORM不是一点半点，据说STORM也基本不更新了，但其实数据量不大，用啥都可以，从应用的角度讲，诸如IBM这种商业版本，是不错的选择，支撑各类实时应用场景绰绰有余。 流处理集群以流处理技术结合内存数据库，用以实时及准实时数据处理，基于IBM Streams流处理集群承载公司的实时业务： 什么样的大数据平台架构，才是最适合你的？ 3、数据分析层，与时俱进吧。 先谈谈语言，R和Python是当前数据挖掘开源领域的一对基友，如果要说取舍，笔者真说不出来，感觉Python更偏向工程一点，比如有对分词啥的直接支撑，R的绘图能力异常强大。但他们原来都以样本统计为主，因此大规模数据的支撑有限。 笔者还是更关注分布式挖掘环境，SPARK是一种选择，建议可以采用SPARK+scala，毕竟SPARK是用scala写的，对很多原生的特性能够快速支持。 TD的MPP数据库ASTER也内嵌了很多算法，应该基于并行架构做了很多优化，似乎也是一种选择，以前做过几度交往圈，速度的确很快，但使用资料屈指可数，还需要老外的支持。 传统的数据挖掘工具也不甘人后，SPSS现在有IBM SPSS Analytic Server，加强了对于大数据hadoop的支撑，业务人员使用反馈还是不错的。 无论如何，工具仅仅是工具，最终靠的还是建模工程师驾驭能力。 4、数据开放层，也处在一个战国时代。 有些工程师直接将HIVE作为查询输出，虽然不合理，也体现出计算和查询对于技术能力要求完全不同，即使是查询领域，也需要根据不同的场景，选择不同的技术。 HBASE很好用，基于列存储，查询速度毫秒级，对于一般的百亿级的记录查询那也是能力杠杠的，具有一定的高可用性，我们生产上的详单查询、指标库查询都是很好的应用场景。但读取数据方面只支持通过key或者key范围读取，因此要设计好rowkey。 Redis是K-V数据库，读写速度比HBASE更快，大多时候，HBASE能做的，Redis也能做，但Redis是基于内存的，主要用在key-value 的内存缓存，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术，但如果数据越来越大，那么，HBASE估计就是唯一的选择了? 另外已经基于IMPALA提供互联网日志的实时在线查询应用，也在尝试在营销平台采用SQLFire和GemFire实现分布式的基于内存的SQL关联分析，虽然速度可以，但也是BUG多多，引入和改造的代价较大。 Kylin当前算是基于hadoop/SPARK的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。 5、数据应用层，百花齐放吧。 每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考： 什么样的大数据平台架构，才是最适合你的？ 6、数据管理层，路漫漫其修远兮 大数据平台的管理有应用管理和系统管理之分，从应用的角度讲，比如我们建立了DACP的可视化管理平台，其能适配11大搭数据技术组件，可以实现对各类技术组件的透明访问能力，同时通过该平台实现从数据设计、开发到数据销毁的全生命周期管理，并把标准、质量规则和安全策略固化在平台上，实现从事前管理、事中控制和事后稽核、审计的全方位质量管理和安全管理。 其它诸如调度管理、元数据管理、质量管理当然不在话下，因为管住了开发的源头，数据管理的复杂度会大幅降低。 从系统管理的角度看，公司将大数据平台纳入统一的云管理平台管理，云管理平台包括支持一键部署、增量部署的可视化运维工具、面向多租户的计算资源管控体系和完善的用户权限管理体系，提供企业级的大数据平台运维管理能力支撑，当然这么宏大的目标要实现也非一日之功。 总结下大数据平台的一些革命性价值。 大数据时代，大多数企业的架构必然向着分布式、可扩展及多元化发展，所谓合久必分，不再有一种技术能包打天下了， 这冲击着传统企业集中化的技术外包模式，挑战是巨大的。 什么样的大数据平台架构，才是最适合你的？ 大数据及云计算时代，面多这么多技术组件，要采用一项新的技术，机遇和风险共存： 对于大数据平台的商业版本，企业面对的是合作伙伴的服务跟不上，因为发展太快，对于开源版本，企业面临的是自身运维能力和技术能力的挑战，对于自主能力实际要求更高。

一. 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 1.1. 系统与子系统 系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。 子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。 1.2. 模块与组件 都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。 模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。 组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。 1.3. 框架与架构 框架是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是可以拿来直接使用或者在此基础上二次开发。 框架是规范，架构是结构。 我在这重新定义架构：软件架构指软件系统的顶层结构。 架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.并由它来指导团队中的每个人思想层面上的一致。涉及四方面： 系统性思考的合理决策：比如技术选型、解决方案等。 明确的系统骨架：明确系统有哪些部分组成。 系统协作关系：各个组成部分如何协作来实现业务请求。 约束规范和指导原则：保证系统有序，高效、稳定运行。 因此架构师具备能力：理解业务，全局把控，选择合适技术，解决关键问题、指导研发落地实施。 架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。 那什么样的系统要考虑做架构设计 技术不会平白无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动。 架构设计完全是为了业务， 需求相对复杂. 非功能性需求在整个系统占据重要位置. 系统生命周期长,有扩展性需求. 系统基于组件或者集成的需要. 业务流程再造的需要. 二. 架构分层和分类 架构分类可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构 业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。 熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。 如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。 2.1. 业务架构（俯视架构）： 包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。 没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。 所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。 看看京东业务架构（网上分享图）： 2.2. 应用架构（剖面架构，也叫逻辑架构图）： 硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。 类似： 应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。 应用架构图关键有2点： ①. 职责划分: 明确应用（各个逻辑模块或者子系统）边界 逻辑分层 子系统、模块定义。 关键类。 ②. 职责之间的协作： 接口协议：应用对外输出的接口。 协作关系：应用之间的调用关系。 应用分层有两种方式： 一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。 另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。 应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。 应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。 应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。 系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。 2.3. 数据架构 数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。 2.4. 代码架构（也叫开发架构）： 子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。 代码架构主要定义： ①. 代码单元: 配置设计 框架、类库。 ②. 代码单元组织： 编码规范，编码的惯例。 项目模块划分 顶层文件结构设计，比如mvc设计。 依赖关系 2.5. 技术架构 技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。 技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。 系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。 2.6. 部署拓扑架构图（实际物理架构图）： 拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。 物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。 三. 架构级别 我们使用金字塔的架构级别来说明,上层级别包含下层： 系统级：即整个系统内各部分的关系以及如何治理：分层 应用级：即单个应用的整体架构，及其与系统内单个应用的关系等。 模块级：即应用内部的模块架构，如代码的模块化、数据和状态的管理等。 代码级：即从代码级别保障架构实施。 战略设计与战术设计 基于架构金字塔，我们有了系统架构的战略设计与战术设计的完美结合： 战略设计：业务架构用于指导架构师如何进行系统架构设计。 战术设计：应用架构要根据业务架构来设计。 战术实施：应用架构确定以后，就是技术选型。 四. 应用架构演进 业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。 架构演进路程：单体应用→分布式应用服务化→微服务 4.1. 单体应用 企业一开始业务比较简单，只应用某个简单场景，应用服务支持数据增删改查和简单的逻辑即可，单体应用可以满足要求。 典型的三级架构，前端（Web/手机端）+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示： 针对单体应用，非功能性需求的做法： 性能需求：使用缓存改善性能 并发需求：使用集群改善并发 读写分离：数据库地读写分离 使用反向代理和cdn加速 使用分布式文件和分布式数据库 单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。下面是单体架构应用的一些缺点： 复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战， 甚至添加一个简单的功能， 或者修改一个Bug都会带来隐含的缺陷。 技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积 越多。“ 不坏不修”， 这在软件开发中非常常见， 在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。 部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中， 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高， 这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。 可靠性差：某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃。 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。 阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题， 团队中的每个成员 都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。 4.2. 分布式 随着业务深入，业务要求的产品功能越来越多，每个业务模块逻辑也都变得更加复杂，业务的深度和广度都增加，使得单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，增加新功能开发周期越来越长，维护成本越来越高。 这时需要对系统按照业务功能模块拆分，将各个模块服务化，变成一个分布式系统。业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。 该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。另外还有以下特点： 降低了耦合度：把模块拆分，使用接口通信,降低模块之间的耦合度。 责任清晰：把项目拆分成若干个子项目，不同的团队负责不同的子项目。 扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。 部署方便：可以灵活的进行分布式部署。 提高代码的复用性：比如Service层，如果不采用分布式rest服务方式架构就会在手机Wap商城，微信商城，PC，Android，iOS每个端都要写一个Service层逻辑，开发量大，难以维护一起升级，这时候就可以采用分布式rest服务方式，公用一个service层。 缺点：系统之间的交互要使用远程通信，接口开发增大工作量，但是利大于弊。 4.3. 微服务 紧接着业务模式越来越复杂，订单、商品、库存、价格等各个模块都很深入，比如价格区分会员等级，访问渠道（app还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的服务化架构，即微服务。 微服务的特点： 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。 单个微服务启动较快：单个微服务代码量较少， 所以启动会比较快。 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。 技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。 微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。 运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。 五. 衡量架构的合理性 架构为业务服务，没有最优的架构，只有最合适的架构，架构始终以高效，稳定，安全为目标来衡量其合理性。 合理的架构设计： 5.1. 业务需求角度 能解决当下业务需求和问题 高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题 前瞻性设计: 能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。 5.2. 非业务需求角度 ①. 稳定性。指标： 高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。 ②. 高效指标： 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。 ③. 安全指标 安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段 六. 常见架构误区 开高走落不到实处 遗漏关键性约束与非功能需求 为虚无的未来埋单而过度设计 过早做出关键性决策 客户说啥就是啥成为传话筒 埋头干活儿缺乏前瞻性 架构设计还要考虑系统可测性 架构设计不要企图一步到位 常见误区 误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。 误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。 误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车→自行车→摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？ 误区4—— 为虚无的未来埋单而过度设计：在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。 误区5——一味追随大公司的解决方案：由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。 误区6——为了技术而技术：技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。 七. 架构知识体系 7.1. 架构演进 初始阶段：LAMP,部署在一台服务器 应用服务器和数据服务器分离 使用缓存改善性能 使用集群改善并发 数据库地读写分离 使用反向代理和cdn加速 使用分布式文件和分布式数据库 业务拆分 分布式服务 7.2. 架构模式 分层：横向分层：应用层，服务层，数据层 分割：纵向分割：拆分功能和服务 分布式 分布式应用和服务 分布式静态资源 分布式数据和存储 分布式计算 集群：提高并发和可用性 缓存：优化系统性能 cdn 方向代理访问资源 本地缓存 分布式缓存 异步：降低系统的耦合性 提供系统的可用性 加快响应速度 冗余：冷备和热备，保证系统的可用性 自动化：发布，测试，部署，监控，报警，失效转移，故障恢复 安全： 7.3. 架构核心要素 高性能：网站的灵魂 性能测试 前端优化 应用优化 数据库优化 可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成 负载均衡 数据备份 自动发布 灰度发布 监控报警 伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器 集群 负载均衡 缓存负载均衡 可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖 分布式消息 服务化 安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。 xss攻击 sql注入 csr攻击 web防火墙漏洞 安全漏洞 ssl 八. 架构书籍推荐 1. 《大型网站技术架构：核心原理与案例分析》 这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。 2. 《亿级流量网站架构核心技术》 相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！ 如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。 3. 《架构即未来》 这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。 4. 《分布式服务架构：原理、设计与实战》 这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。 5. 《聊聊架构》 这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。 不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。 6. 《软件架构师的12项修炼》 大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

越来越多的企业家有一个共识，一个企业永远只做两件事：一是战略，二是执行。所谓“三分战略定天下，七分执行决输赢”就是这个道理。日本经营之神松下幸之助更是认为：“一个企业的成功，20%在战略，80%在执行。”可见，没有执行力就没有竞争力。 但是，很多企业在执行上存在问题。最典型的表现是流程繁琐，行动迟缓，互相推诿、执行低下。别人已经干起来，自己还在反复论证“怎么干”，所以失去了市场先机。IBM总裁郭士纳说：“超级的战略执行并不仅仅是做正确的事，而是必须是比竞争对手更快、更经常和更有效地去做正确的事。战略制定以后，动作一定要快。不要怕犯错误，即便是犯错误也要由于我们动作太快而不是太慢。” 可以这样说，执行效率低下犹如企业的“毒瘤”，不及时割除，必然发生癌变，企业最终被市场淘汰。那么，应该如何提升团队执行力，打造一支狼性团队呢？需要抓好一个重点、两个前提、三个管理和四个心态。 一个重点：拿结果 执行的最终目的就是获取预想的结果，所以每个人都要有结果思维。什么是结果思维？结果思维是责任思维+分析思维+价值思维+效率思维，即做任何一件事都必须做到讲责任、善分析、有价值、高效率。 任何一个组织，均是以结果为导向来衡量员工的价值。没有结果，你的劳动就没有价值。犹如战场上，指挥员让你拿下对面山头，你把人拼光了也没有攻上去，能给你记功吗？非但不会立功受奖，还会拉出去毙了。 拿结果，需要明确三个要点：一，完成任务不等于完成结果。二，好的态度不等于好的结果。三，履行责任不等于有好的结果。好的结果一定要具备三要素。1，能衡量。即结果是量化的。2，有价值。即结果是符合预期。3，可交换。即结果可以为你的劳动支付报酬。 两大前提：定目标+定责任 1，定目标。 人都有惰性，而惰性恰恰是执行力的天敌。为了打掉人所固有的惰性，必须有一种牵引力，这就是目标管理。巴纳德说：“目标管理的最大好处是，它使员工能够控制他们自己的成绩。这种自我控制可以成为更强烈的动力，推动他尽最大的力量把工作做好” 需要注意的是，制定组织和员工个人目标时，一定是现实主义的，不害怕提出高目标，又不让目标超出员工的能力。格力总裁董明珠说：“顺手就可以拿到的东西，不叫目标，一定要跳起来才能达到的东西才是目标” 2，定责任 责任是一种驱动力，这对执行力非常重要。自动自发的主动执行力固然好，但是在思想多元化的社会大背景下，无异于缘木求鱼。所以，基于责任基础上的被动执行力是不可或缺的。没有责任，干与不干一个样，干好干坏一个样，谁会去干呢。 责任怎么定？有三大内容：一，明确职责分工：这件事由谁去做。二，明确工作任务：包括工作内容、工作量、工作要求、目标、完成时限等。三，明确业务流程：从哪里开始，执行路径，到哪里终止。 三项管理：沟通管理+时间管理+自我管理 1，沟通管理 威尔德说：“管理者的最基本能力：有效沟通。”要激励下属高效执行，就必须拆掉横亘在领导和下属之前的无形之墙。聆听员工心声，了解员工需求，尊重员工建议。切不可高高在上，不可一世，妄自尊大，颐指气使。 员工执行力不好，很多时候是沟通出了问题。沟通时要做到五个讲清：一是指令讲清。即要干什么。二是目标讲清。即要干到什么程度。三是后果讲清。即完不成的后果是什么。四是责任讲清。这件事你全权负责。五是细节讲清。有哪些需要注意的地方。 2，时间管理 世界首富比尔·盖茨说过一句话：“观念+时间才是真正的财富。”一个优秀的管理者，首先是一个时间管理的高手。做任何事情都要明确的时间表，并明确规定两个时间，一是开始时间，二是结束时间。只知道什么时候开始，不知道什么时候结束，不可能有执行力。 做好时间管理，必须合理分配好自己和下属的时间。需要应用80/20原则，即将工作任务按轻重缓急分类：A、很重要+很紧急；B、很重要+不紧急；C、不重要+很紧急 ；D、不重要+不紧急。用80%的时间解决重要的事情，20%的时间处理琐事。 3，自我管理 自我管理又称为自我控制，是指利用个人内在力量改变行为的策略。即通过对自己的目标、思想、心理和行为进行管理，自己管理自己，自己约束自己，自己激励自己，自己管理自己的事务，从而实现内控式管理。 自我管理需要从关注细节和提升素养开始，应引导员工建立以下八个做事原则：1，要事第一。2，计划管理。3，任务清单。4，日事日毕。5，杜绝拖延。6，分类整理。7，马上行动。8，每日复盘。 四种心态：匠心+野心+开心+恒心 1，匠心 匠心，指能工巧匠的心思。而匠心精神，则更多地强调专注和创新，即用心做一件事的心态。正如华为任正非所言：“尽心工作与尽力干活是两回事。用心的干部即使技术上差一点也会赶上来，因为他会积极开动脑筋想方设法去工作。” 《亮剑》中，李云龙的独立团执行力堪称完美，因为李云龙就是一名具有匠心精神的指挥员。打山崎大队的时候，程瞎子组织了数次进攻都无功而返。换作李云龙的独立团上场，土工作业+手榴弹雨，立刻报销了嚣张的山崎大队。 2，野心 一个员工，一个团队，都需要点野心。野心是成功的欲望，更是一种强劲的自驱力。员工没有野心，就会产生小富即安的思想，整天想着躺在功劳簿上数钱。团队没有野心，就会目光短浅，失去竞争的血性。 雷军曾经说：野心和执行力，才是一个人最核心的竞争力。一个被巨大野心驱动的人，会极度自律、昼度夜思、殚精竭虑、不知疲倦，因为他不是想赢，而是必须赢。就如杰克韦尔奇在《赢》这本书中所言：“有必赢的心态，执行力才是强大的” 3，开心 蓝斯登定律指出：给员工快乐的工作环境，能够产生强大的执行力和凝聚力。快乐的员工，会主动积极地投入工作，发挥他们真正的潜力，而且能把他们的快乐带给客户，从而能够维护企业形象，扩大销售利润。 让员工快乐工作，需要遵循四个原则：原则一：允许表现，即不要有官僚文化。原则二：自发的快乐，如尊重员工的工作意愿。原则三：信任员工。信任产生激励。原则四：重视快乐方式的多样化。如环境改善、丰富福利、团建活动等。 4，恒心 稻盛和夫被日本人称为经营之神，白手起家创办了两家世界 500 强企业，京瓷和 KDDI。稻盛和夫所著《六项精进》一书中说：一切成功，皆来源于付出不亚于任何人的努力。其实，这也是执行力的核心精要之一。 一个团队，执行力最大的问题是什么？并不是目标高不可攀，而是做事虎头蛇尾，甚至是半途而废。执行过程，困难是常见的，挫折也是难免的，唯有咬定目标，坚忍不拔，全力以赴，坚持到底，才能最终拿到想要的结果。

    禅道的数据库命名都比较简明扼要，从字面意思应该都可以猜出来表的用途。如果还不是很清楚的话，可以到每个表对应的模块下面的语言文件里面查找。        最新版本可以在  禅道 后台---二次开发---数据库 中查看相应的表介绍。 一、我的地盘相关的表 zt_todo，待办事宜表。 二、产品相关的表 zt_product，记录了产品相关的信息。 zt_productplan，记录了产品的计划信息。 zt_story，是非常重要的一张表，记录了系统中所有的需求记录。 zt_storyspec，记录了需求的描述信息。 zt_storystage，记录需求的阶段信息。 zt_release，记录了产品的发布信息。这张表同时也和zt_build互相关联。 zt_branch，记录产品的分支和平台信息。 三、项目相关的表 zt_project，项目表。 zt_projectproduct，记录了项目和产品之间的关联关系。 zt_projectstory，记录了项目中需要做的需求列表。 zt_task，任务表。 zt_burn，燃尽图数据表。燃尽图就是根据这张表的数据画出来的。 zt_team，记录了项目中的团队成员。 zt_build，记录了项目中产品的版本列表。 zt_taskestimate，项目任务工时表。 四、测试相关的表 zt_bug，bug表，也是大家非常熟悉的一张表了。 zt_case，用例表。记录了所有的测试用例。 zt_casestep，则是记录了用例相关的步骤，包括历史。 zt_testtask，测试版本表，记录了历次的测试任务。 zt_testrun，则记录了每个测试任务所对应的用例执行情况。 zt_testresult，记录了每个用例历次执行的结果。 zt_testsuite，测试套件表。 zt_suitecase，套件用例表。 zt_testreport，测试报告表。 五、文档库相关的表 zt_doclib，记录了自定义文档库列表。 zt_doc，则记录了所有的文档。 zt_doccontent，文档的内容表。 六、组织管理相关的表 zt_user，用户表。 zt_group，分组表。 zt_usergroup，用户和分组之间的对应关系。 zt_grouppriv，分组的权限。 zt_dept，部门结构表。 zt_userquery，用户自定义查询表。 zt_usertpl，用户的自定义模板表。 zt_usercontact，用户联系人表。 zt_company，这张表记录了当前公司的信息，也是顶级的一张表。 七、后台管理相关的表 zt_action，系统日志表。 zt_cron，定时任务表，记录计划任务。 zt_extension，插件表。 zt_history，操作历史表，记录对任何一个对象的所有修改记录，前后值的变化。 zt_lang，语言定义表。 八、其他模块相关的表 zt_module，也是非常重要的一张表，它维护了禅道系统中的模块划分数据，比如需求的模块划分。 zt_effort，日志表。 zt_entry，应用表。 zt_log，接口日志表。 zt_mailqueue，邮件列队表。 zt_module，模块表，记录模块信息。 zt_notify，提醒信息表，记录所有的提醒信息。 zt_score，积分表，记录积分信息。 zt_file，附件表。记录了所有的附件。 zt_block，区块表，记录我的地盘首页，产品主页，项目主页，测试主页的区块信息。 zt_config，系统配置表，记录所有的基本配置信息。 zt_webhook，记录webhook信息。 zt_webhookdatas，记录webhook的数据表。