草原上的建筑- 草原上的建筑模型-玉龍之鄉

1、数据归集方面： ●根据数据资源目录和数据标准规范，各政府部门整理相关业务系统日志数据、数据资产管理、经济指标、社会管理、政府热线等子系统所需的数据，通过政府信息共享平台、数据开放平台、数据交易平台归集到城市政府大数据库； ●通过互联网数据采集工具，有针对性的抓取经济指标、社会管理、政府热线个试点分析所需的辅助数据到统一的社会数据归集子系统，通过统一的社会数据归集子系统交换至城市政府大数据库。 ●针对经济指标、社会管理、政府热线等试点数据分析应用，建立支撑专题库构建的整合库和全文库，以及在整合库、全文库的基础上协助来穗局、政务办等部门建设试点应用的专题库。 2、大数据平台建设方面： ●建设政府信息共享平台、数据开放平台、数据交易平台对接的接口系统，用于支撑政务类数据归集工作； ●建设统一的社会数据归集子系统，用于解决社会类数据归集工作； ●依托城市政府大数据库及相关专题数据库，协助相关部门建设重点行业产能分析、地区交易活跃指数、社会管理大数据分析、政府热线大数据分析，为政府部门运用大数据进行社会精准治理与多方协作提供应用支撑手段。 3、整合应用、大数据分析方面： 基于专业大数据平台软件、BI系统软件、关系挖掘系统软件、GIS系统软件等大数据支撑软件，利用通用的大数据算法与模型，对公共的大数据挖掘分析处理服务能力进行整合，形成可复用的软件组件，为各委办局、各行业开展“大数据专题应用”建设提供开发平台支撑。各委办局、各行业的专题应用可直接在政府大数据综合应用管理平台上基于各种软件组件来开发建设，以有效利用统一的大数据平台资源，避免重复投资建设，各部门、各行业可以更专注于大数据应用业务的开展。 4、管理应用方面： ●大数据平台还应提供专属大数据空间管理服务功能，满足 “私有化”管理各自数据、应用的需求。 ●通过引入服务运营机制，为大数据平台提供更多的软件组件服务和专题应用开发供应商，促进大数据平台的应用推广和完善。

随着技术的发展，路由器和防火墙很多功能已经重叠，大家都支持，比如：路由功能（静态路由/RIP/OSPF/BGP等）、NAT、ACL、DHCP等等。那么网络出口究竟选择路由器还是防火墙呢？ 术业有专攻 防火墙：本质是安全设备，虽然集成了很多路由功能，但很多路由器高级功能它也无能为力，比如MPLS VPN、MPLS TE。多业务接入，比如运营商甩过来的是ATM、POS线路。 路由器：现在路由器也集成了部分防火墙的基础安全功能，但重点还是在路由，MPLS VPN/TE、广域网优化等还是防火墙无可替代的功能，而且表项更加丰富，能支持超大规模网络。 路由器防火墙应用场景分析 1. 一般中小型企业、政府政务外网、中小学等网络出口都会选择防火墙，简单省事，性能要求不高，买一台设备啥功能都有（现在主流都是下一代防火墙，集成防火墙、行为管理、负载均衡、流量控制、VPN等各种功能） 中小型网络使用防火墙出口较多 2. 特定行业出口必须选择路由器，比如公安内网、电子政务内网、法院/检察院内网（第一是政策要求，第二是为了实现对等通信，比如公安内网里面，要求公安部能够访问到最底层的民警，严禁在网络内部接入防火墙，如果中间加些防火墙，很多流量就被干掉了） 特定行业/网络 出口必须使用路由器 3. 大型企业/高校校园网 网络出口基本也使用路由器，专门负责路由、NAT功能，一般也会部署防火墙，专门负责安全功能，术业有专攻！（其实很多中小单位也是这张架构，可能防火墙/路由器都是2台冗余，出口多运营商多链路） 大型网络 路由器与防火墙并存（术业有专攻） 运营商/公安/金融骨干网设备都是运营商，参考图片如下： 中国电信Chinanet 骨干节点都是高端路由器 路由器/防火墙使用总结 一般中小型单位 互联网出口使用防火墙，简单实用，功能多还便宜。（或UTM、行为管理、负载均衡、广域网优化、多业务路由器等设备都可以，基本都是功能多合一） 特定行业必须用路由器，政策要求和业务需要。 大型网络防火墙和路由器分开，如果都用防火墙，性能可能扛不住。其实现实中很多中小型网络也习惯路由器和防火墙分离，术业有专攻！

1 软件项目管理中，项目进度把控重要性不言而喻，深入落实到细节对项目进度非常有帮助。项目进度管理重要性主要表现在两方面： 项目进度管理的地位 01、项目管理集中反映在项目成本、质量和进度三个方面 通常称为项目管理的“三要素”。进度是三要素之一，对进度的要求是通过严密的进度计划，使项目能够按时按质完成。 02、项目进度管理的影响因素 项目范围会影响项目进度。一般来讲,项目模块越大,项目所要完成的任务也就越多,所需的工时也就越多。 项目成本、质量也都会影响进度。一般情况下，追加成本,可以增加更多的进度管理,比如新增开发人员,从而使某些工作能够并行完成或者加班完成。 要是没有很好的进度计划，团队成员很难在一个长的时间跨度内掌控和汇报项目进度。计划与实际工作脱节，对于掌控项目的进度非常不利。 项目负责人经验缺乏，管理不到位也会影响项目进度。由于项目负责人缺乏相应的项目经验，事前没有很好的进行规划分析，制定应急计划，等事情发生了才手忙脚乱不知所踪。管理组织上不能够保证进度目标的实施，人浮于事，重关系、轻能力现象严重，导致执行能力很差。项目成员只关心自己是否得利，而不管项目目标是否顺利实现。 缺乏有效的监督、激励、考核机制，目标分解不够明确，在进度滞后的情况下找不到直接的负责人，开发人员彼此之间互相推脱责任。由于没有明确的责任又缺乏合作精神，项目成员的积极性调动不起来，对进度目标也就很漠然。 2 笔者曾负责实施某电子商务企业进销存管理系统。在项目规划阶段，笔者主要通过对项目进行合理分解，正确估算各个任务的工作量，制定出详细的项目进度管理计划。 在项目实施过程中，根据基线计划，对项目进度进行有效的跟踪和监控，同时关注可能导致进度延期的项目风险因素，实现动态资源平衡等方法有效管理和控制项目进度。 在项目计划阶段，项目组要对项目任务进行合理分解，正确估算各个任务的工作量，制定详细的进度管理计划。对项目任务进行了分解，得到了一个较为详细的工作分解结构WBS。 项目任务分解完毕后，对项目设立了相应的阶段里程碑，比如需求分析、系统概要设计、系统详细设计、系统单元测试、系统集成测试、系统试运行、项目验收等阶段。 对项目进行任务工期估算。在工期估算方面，根据以往的项目经验，大致估算出各模块的工作量，并依据项目投入的开发人员，计算出每个任务的起止时间，形成了初步的项目进度计划。 在估算项目工期时，考虑了活动清单、资源需求、人员能力等因素，以及环境和和风险因素对工期的影响，在一些关键活动处预留了一定冗余时间以应对项目风险。 有了对工期的估算，再结合详细的WBS，预估每个模块最迟完成点。有了这些基础的数据后，就形成了项目的整体进度计划，并将进度计划在项目组内部评审后，提交给领导和客户负责人进行审核确认。 3 项目进度管理如此重要，那么如何做好项目进度管理，这里有几点建议可以参考 01、做好项目进度表，明确人员分工 这一环节看似简单，却直接关系到整个项目能否顺利完成。所以，在项目计划阶段，我们一定花足够多的时间来做好项目进度计划，在对分解项目任务时，颗粒度尽量细一些，确保每个环节具体到相关具体人员，并确定好任务截止时间。 项目进度表可以用jira或其他项目管理工具，来保持随时汇报项目进度。作为项目经理，要及时对项目任务进度进行跟踪和监控，及时发现和纠正任务偏差。由于在制定项目进度计划时，每位项目组成员都清楚自己任务的完成时间表，以及任务完成标准，项目任务能直接关联到每位开发者。 02、优化作业流程，确定工作标准 项目组成员间的作业流程，是通过邮件、钉钉还是其他项目管理工具沟通，在项目启动会上一定要明确清楚。我们可以把作业流程分为 需求收集 需求评审 进度管理 缺陷管理 评审回顾 每个流程由一位或者多位负责，尽量不要超过三位。任务状态变更后，再进入到下一个流程。 该项目任务并行较多，要是有项目助理，可以由项目助理按期检查任务完成情况，必要时相关工序人员交叉验证，同时按期汇总检查情况。对于出现任务进度延迟，由相关任务责任人提出解决方案，通过加班、寻求协助等方式完成。 03、定期检查项目节点/里程碑 很多时候我们会多个项目同时进行，或是还有很多其他日常工作，那么如何保障项目正常运行，这需要我们时常检查项目节点/里程碑，及时发现项目中可能的风险。要是中间有某个需求变更，需要调整，这时我们就需要尽快找相关负责人沟通。 还需要特别注意关键路径上的任务，尤其是开发和测试阶段的任务，这两个阶段的任务为关键活动，也是项目成员的薄弱环节，项目组面临很多技术难点。 笔者在负责进销存系统，有两位这方面经验丰富的程序员，并同其他工作组成员讨论技术细节问题，对于项目组确实无法解决的技术难题，则需要协调其他资源来解决，这样不至于因为某一个技术细节而影响整个工程进度。 04、项目成员的沟通 项目执行过程中的沟通也是非常重要的，来确保项目进度的信息透明和对称。如果A组已经做好某件事，需要B组做另外的事，如果没有及时反馈沟通，B可能压根就不知道，这样有可能导致项目进度延误。 一般情况下，项目组会定期召开项目进度会，和项目成员同步进展情况，并再次确认各项任务的截止时间。但如果项目组有用到项目管理工具协作和沟通，信息比较公开透明的话，项目进度会就没有必要太过频繁。当然，和关键干系人的沟通还是必不可少的，可以定期核对项目进度。 每天上班时，抽个10来分钟开个站会，对各成员提交的进度数据进行比对和汇总，总结问题，对于关键路径的任务进度偏差部分，要进行分析，提出纠正和预防措施。 05、项目团队的激励 想让项目成员工作起来更有激情，仅仅依赖管理制度是远远不够的，项目负责人要信任每一位成员，并注意成员的工作状态，适当增加成员在执行任务中的乐趣，做得好的一定要及时鼓励，培养成员的积极性和自我成就动机。整个团队有干劲了，项目的完成也就是水到渠成的事了。 一起荣辱与共、互相信任、 跌宕起伏、艰难困境，依然能迎难而上，积极面对，形成一股凝聚力。人在一起不是真正的团队，心在一起才是凝聚力强的团队。 在项目开发过程中，也遇到一些问题，比如，在系统集成测试阶段，系统兼容性，客户方参与度不足等。在今后的项目中，笔者会不断努力和改进，以求更加高效地完成项目任务。

1.职能制组织结构 （1）优点： a.结构简单、分工明确。 b.权责划分清晰。 c.管理成本较低。 （2）缺点： a.各职能部门间横向配合易出现问题。 b.过分强调各部门专业分工，忽略融合统一。 c.组织达到一定规模后，可能由于集权造成沟通不畅。 2.事业部制组织结构 （1）优点： a.企业灵活性和适应性更强，权利下放，总公司高层能够从日常管理工作中解放出来。 b.通常能够保证公司的稳定业绩。 c.有助于培养团队的接班人。 （2）缺点： a.横向与纵向之间沟通与协调工作较为复杂。 b.需要的管理结构较多，管理人员较多，管理成本较大。 c.对上容易架空总公司领导，让总公司失去对事业部的控制。 d.事业部间存在竞争，产生内耗，较难协调。 3.矩阵式组织结构 （1）优点： a.强化组织中的横向联络，让横向与纵向联络相结合。 b.提高组织的机动性与灵活性。 c.激发团队协作意识，提高人力资源的工作效率。 d.有效地实现分权管理。 （2）缺点： a.双重领导可能会造成员工的无所适从。 b.员工组合有临时性的感觉，可能造成责任感不强。 c.项目小组的负责人可能出现权利较小，责任较大的问题。 4.多维立体组织结构 该组织机构是对事业部制组织结构扩展，增加了区域维度，管理更加复杂，适合于跨地区企业。 5.模拟分权式组织结构 （1）优点： a.适应更强，可以作为职能型组织机构管理上的补充。 b.能够激发各部门的积极性，提高组织活力，提供效率。 c.相比职能型组织，权责利划分更清晰，员工责任感更强。 （2）缺点： a.相对职能型，组织的横向沟通和交流难度更大。 b.许多职能部门的计划和目标难以量化。 c.内部价格的确定容易引发扯皮或矛盾。 6.流程型组织结构 （1）优点： a.实现组织的扁平化管理，高层信息容易传达到基层。 b.横向沟通更顺畅，减少部门间的扯皮和不配合。 c.组织的一切努力都是围绕市场和顾客为导向，提高组织运行效率。 d.组织的适应性和灵活性更强。 （2）缺点： a.流程的设计、确定、修改等工作较为复杂困难。 b.与传统纵向管理方式差别较大，员工接受度较低。 c.对员工能力素质要求较高。 7.网络型组织结构 （1）优点： a.能够优化各企业之间的资源配置，实现优势互补。 b.降低企业的管理成本，提高沟通效率。 c.有利于激发团队精神，促进员工之间相互合作。 d.组织的适应性和灵活性更强，变化更迅速。 （2）缺点： a.企业或个体之间的关系较为复杂，出现问题难以协调。 b.有泄漏组织核心机密的风险，可能会增加潜在竞争对手。c.需要一定的能力和技术支持。 8.合弄制组织结构 （1）优点： a.属于生态型组织，员工可以自由组合团队。 b.体现人性化管理，最大限度地释放了人的创造性。 （2）缺点： a.虽然团队自组织化程度较高，但无法满足所有成员都处于自己意愿的“圈子”。 b.不同圈子的创造价值不同，价值回报不同，薪酬处于可上可下动态过程，并非所有人都能接受。 c.需要适应不断适应不同圈子的文化，对人的适应性要求较高。 9.阿米巴模式组织机构 优点： a.随市场变化而变化，对外部市场的传导和适应性更强。 b.通过内部交易，实现了阿米巴组织之间内部核算，管理效率更高。 c.实现全员参与经营，培养具有经营意识的领导。 （2）缺点： a.建立在经营哲学上，对企业负责人和高管思想意识和理念要求比较高。 b.阿米巴间内部定价容易出现分歧后，需依靠经营者大局观解决。 c.倡导的大家庭文化，对目前国内现行多数企业的企业文化是一种挑战。 小结： 企业常用的组织机构基本就这九种，大家可以根据企业规模、发展阶段、行业特点进行选择。

一下关于标书，你需要知道的一些问题。 一、标书的定义 标书包括招标书和投标书，也叫招标文件和投标文件。一般情况下，我们所讲的标书都代表着投标文件。 招标书是一种告示性文书，它提供全面情况，便于投标方根据招标书提供情况做好准备工作，同时指导招标工作开展。 投标书是指投标单位按照招标书的条件和要求，向招标单位提交的报价并填具标单的文书。要求密封后邮寄或派专人送到招标单位，故又称标函。是投标单位在充分领会招标文件，进行现场实地考察和调查的基础上所编制的投标文书，是对招标公告提出的要求的响应和承诺，并同时提出具体的标价及有关事项来竞争中标。 投标书是招标工作时甲乙双方都要承认遵守的具有法律效应的文件，因此逻辑性要强，不能前后矛盾，模棱两可，用语要精练，要简短，对政策法规的准确理解与执行，有利于标书制作者剔除歧视性条款。 二、标书的制作流程 1、投标项目报名及招标文件购买 1.1、投标人的选定。依照招标公告及招标文件中规定的合格投标人所具备的条件和采购设备所属的医疗器械类别，选定符合合格投标人条件及具有该设备经营资格的1-3名投标人。 1.2、招标文件的购买。详细阅读招标文件规定的报名方式、报名所需提供的资料及报名费用，并准备报名所需的资料及报名费用。注意报名截止日期。 报名方式分为：现场报名或资质文件传真报名（详见各招标文件具体要求）。 现场报名，需携带报名所需的资质文件及报名费用到指定地点进行报名。提交资质文件及缴纳报名费用后，向招标代理机构索取招标文件和发票或收据。 资质文件传真报名，需将招标文件要求的资质文件及报名费用汇款凭证传真至招标文件指定的传真号码，传真后打电话确认招标代理机构是否收到并索取招标文件。 报名常用资质文件包括但不限于： 法人代表授权委托书 投标人营业执照 投标人医疗器械经营许可 投标人税务登记证（国税、地税） 报名费用缴纳凭证或现金 注：根据招标文件的具体要求提交资质证件的正本或副本、原件或复印件（复印件必须加盖公章），及其他特殊要求的资质文件。 报名费用缴纳方式：现金缴纳或银行转账。 现金缴纳需要委托代理人携带招标文件规定的报名费用到招标文件要求的指定地点进行现场缴纳并索取发票或收据。 银行转账缴纳，提取招标文件中的汇款要求填写支付申请单交由财务进行汇款（应提醒财务在汇款单备注标明招标编号及用途，方便公司汇款查询及招标机构收款查询，如招标文件另有其他要求应严格执行），汇款后将汇款凭证传真至招标代理机构，并打电话确认。涉及到陪标单位，需先通过我司的私人账户将费用汇至陪标公司指定的私人账户，汇款后需通知对方查收并督促、监督对方通过陪标公司的公帐将费用汇入招标文件指定账户，并索取缴纳凭证。电话询问招标机构是否收到。 2、投标保证金的缴纳 详细阅读招标文件关于投标保证金的缴纳说明，明确保证金提交形式、保证金缴纳金额、保证金截止日期，提取重要信息填写支付申请单，交由财务办理，具体程序同报名费用缴纳相同。 投标保证金缴纳方式：银行转账或电汇、现金缴纳、银行汇票等形式。具体操作需严格按照招标文件要求执行。 注：保证金的缴纳预计在截至时间前4天左右缴纳，以防特殊情况导致保证金不能及时到账而错过时间废标。汇款完成后两个工作日内应打电话咨询招标机构是否保证金已到账。 保证金汇款回单必须按招标文件要求密封。 3、投标书制作 3.1、投标价格确认：仔细阅读招标文件提取相关信息填写“项目情况一览表”，交由项目负责人确认投标报价及其他需要负责人确认的相关事宜。 3.2、资质文件的收集：列明招标文件要求的资质文件清单，并逐一准备确认证件的有效期、经营范围等关于资质文件时效性、经营范围等相关信息，需要他人提供的资质文件，需提前告知对方，并规定对方最晚提供资料的时间。如对方快递资料，需先所取文件的扫描件再索取快递公司电话、快递单号，进行及时跟踪以确保文件能及时送到。如对方有无法提供的文件，应列举清楚并及时作出处理决定。如过期资质文件需自行整理、修改的，需严格按照资质文件相应的法律法规规定的形式、日期期限进行修改，务必做到前后一致（原则上修改前后要征得公司同意和认可）。搜集整齐的资料，按顺序放好，编排整齐方便标书最后的顺序整编。 资质文件分为：投标人资质文件、产品供应商资质文件及货物证明文件。 投标人资质文件包括但不限于： 投标人营业执照副本 投标人医疗器械生产或经营许可证副本 投标人税务登记证副本（国税、地税） 投标人组织代码证副本 投标人近期财务报表或审计报告（资产负债表、现金流量表、损益表） 投标人近期纳税证明 投标人近期社会保险缴纳证明 投标人获奖证书、荣誉证书、ISO认证证书等其他提升投标人形象的相关文件 项目负责人及主要技术人员的学历证明或职称等级证明 产品供应商资质文件包括但不限于： 针对投标项目的产品授权书（如供应商为经销商，需出具产品生产商或总代理出具的经销授权） 供应商营业执照副本 供应商医疗器械生产或经营许可证副本 供应商税务登记证副本（国税、地税） 供应商组织代码证副本 供应商获奖证书、荣誉证书、ISO认证证书等其他提升供应商形象的相关文件 货物证明文件包括但不限于： 医疗产品注册证、登记表（注册证过期，应提供药监局出具的延期受理证明） 进口、出口产品应有EN认证、FDA认证或CE认证 国产产品属于强制性产品目录的应具有CCC强制性产品认证 其他特殊产品应具有该产品所属行业领域的相关认证和注册证明 注：请根据招标文件具体要求提供相应资质证明文件，及其他特殊的资质证明文件。 3.3、投标书格式文件的填写：按照招标文件提供的格式逐一顺次填写，边填写边检查。 价格文件的填写：注意价格大、小写、单价、总价、总计是否一致。 资格文件的填写：注意语句描述是否通顺、是否有错别字以及标点符号。 商务和技术偏离表的填写：应对招标文件的商务条款、技术条款逐一填写响应，主标设备勿出现负偏离。陪标设备勿出现正偏离。根据招标文件中的评分标准，粗略计算得分，不得出现陪标得分高于主标得分。 产品配置：严格依据厂家提供的配置。不能任意多加，也不能随意删减（除非有意改动要征得公司同意）。 3.4、投标书的初步整理：将3.3项内所有格式文件与资质文件编排制一起。进行目录的初步编排，并检查主标与陪标文件勿出现交叉及雷同现象。 3.5 如果招标文件没有要求，页码最好手写。 3.6 根据手写的页码，来完善目录页码 注：对招标文件个别条款不明确的，应及时与招标机构沟通，以确保及时有效的完成投标文件的编制。 4、投标文件的检查工作 在投标文件编排完整自检之后及没有出现明显错误的前提下，将投标文件交由项目负责人审查（采取交叉审核的方法）。投标文件审查时间定在投标代表索要投标书日期的前2天交由负责人审查。 5、投标文件的签字盖章 对审查及修改完毕的投标文件进行签字盖章。 5.1、签字应注意法定代表人签字、授权代表签字及见证人签字的名字。法定代表人为投标单位营业执照上的法人代表。授权委托人为代表投标单位参加投标的委托人。见证人为证明法人代表及授权委托人的其他人。 注：委托代理人或见证人要与办理项目报名事宜的委托代理人一致，主标与陪标文件勿出现人名交叉及雷同现象（建议提前草拟好签字人名单，防止时间紧急时签字失误）。 5.2、对投标文件的盖章。投标文件应逐页盖章，如该页标明“盖章”的位置，章应盖在指定位置之上。如未标明“盖章”位置，应盖在有投标人名称的位置上。如未有投标人名称，应压住文字盖在页面的右下方。 注：投标人公章勿盖在其他公司公章之上。如现有的投标人公章与文件中原有的投标人公章不一致时，应将文件替换成无公章件再盖章。如招标文件规定复印件也需要加盖红章，应将投标书复印完再加盖公章，不可在有公章的复印件上加盖公章。 6、投标文件的复印、装订及密封 6.1、投标文件的复印。将排版完整、签字、盖章后的投标文件，按照招标文件规定的投标文件副本份数+1（“1”为公司备份件）进行复印。复印后应检查复印的是否清晰，有无缺页、夹页、顺序颠倒、页面倒转现象。 6.2、投标文件的装订。将复印好的投标文件按照招标文件要求的装订方式装订，如招标文件无要求装订方式，可自行选择装订方式。装订方式分为打孔、胶装（建议用打孔，便于发现错误时做改动，但要注意装订是否牢固，不得出现活页、掉页）。 6.3、投标文件的密封。根据招标文件要求准备投标文件密封袋。主标与陪标文件应在符合招标文件密封要求的前提下，变换包装的颜色、形式、字体，勿出现雷同现象。如招标文件未详细规定密封要求，可自行进行标书密封，主标与陪标文件应变换包装的颜色、形式、字体，勿出现雷同现象。 6.4、投标文件的封口。在未得到项目负责人或投标代表同意的前提下，投标文件封口不得密封。应贴好双面胶及盖好骑缝章后预留封口，由投标代表整理后自行密封。 7、开标前的准备工作 在完成投标文件密封准备工作后，应将开标时间、开标地点、招标机构联系人、联系电话、招标文件、投标文件明细清单及招标文件规定其他在开标前需要提交的资料（包括但不限于：投标代表人身份证原件及复印件加盖公章、投标保证金缴纳凭证加盖公章或现金、公章、印盒、修改文具等）交由投标代表熟悉和备用。 8、开标后的整理、跟进工作 （备用）投标文件收回存档。 公司信息、产品信息、文件资料整理归档。常用的建立纸质资料夹。 召开投标总结会议（开标后的1周内）。 中标公告公示期满后，办理中标通知书领取、投标保证金退还、中标单位中标服务费缴纳、合同签订等跟进工作。具体办理应与招标机构沟通。应及时告知陪标公司注意查询投标保证金是否退还，如退还应及时督促陪标公司将公司原先汇入陪标公司的投标保证金退还回来，并告知公司财务查收。同时建立保证金往来档案。 三、如何编制一份完美的标书 标书的逻辑性要强，不能前后矛盾，模棱两可；用语要精炼、简短。因此，投标书的编制决不可轻视，一定要由专业人士编制。

内蒙古自治区行政区划图 1949年 撤销阿巴哈纳尔左翼旗，阿巴嘎左翼旗，浩齐特右翼旗，合并设立中部联合旗。 撤销喜扎嘎尔旗，并入科尔沁右翼前旗。 撤销太仆寺旗，分别设立太仆寺左旗，太仆寺右旗。 察哈尔右翼正蓝旗更名为正蓝旗。 林东县更名为巴林左旗。 3月21日，内蒙古自治区政府决定，乌兰浩特市、突泉县划归兴安盟领导。 4月11日，撤销巴彦旗，并入莫力达瓦旗。 4月11日，撤销呼伦贝尔盟、纳文慕仁盟，合并设立呼纳盟。 4月11日，扎赉诺尔街并入满洲里市，成为满洲里市的一个区（即今扎赉诺尔矿区）。 5月1日，中共中央东北局决定，热河省的昭乌达盟、辽北省的哲里木盟划归内蒙古自治区。 11月23日，内蒙古自治政府主席乌兰夫呈请中央人民政府政务院总理周恩来，为便于对内蒙古西部地区的领导，将内蒙古自治政府由乌兰浩特市迁驻张家口市。 11月24日，周恩来总理批复，准予内蒙古自治政府迁驻张家口市。之后，内蒙古自治政府陆续迁驻张家口市（12月23日开始办公，1950年6月25日迁移全部完毕。） 12月2日，中央人民政府决定内蒙古自治政府改称内蒙古自治区人民政府。 1950年 1950年1月，周恩来总理在北京召见乌兰夫、刘春等，研究内蒙古自治区的划界问题。周恩来总理根据党中央和毛泽东主席的指示，确定将历史上属于内蒙古的区域划归内蒙古，建立东西部统一的内蒙古自治区。关于内蒙古自治区首府问题，考虑到归绥市在历史上曾是内蒙古的中心，根据乌兰夫的意见，将内蒙古自治区首府设在归绥市。 撤销太仆寺右旗，明安旗，合并设立明安太右联合旗。 撤销察哈尔右翼正白旗、察哈尔右翼镶白旗，合并设立正白镶 白联合旗。 撤销乌珠穆沁右翼旗、乌珠穆沁左翼旗、东浩济特旗，合并设立东西乌珠穆沁东浩济特联合旗。 内蒙古自治区人民政府批准，察哈尔盟驻地由明安太右联合旗女子部迁至宝昌县城关。 1月23日，内蒙古自治区人民政府批准，设立喜桂图旗，由牙克石街、索伦旗的扎罗木得区、免渡河区及布特哈旗的博克图努图克（区）为其行政区域。旗政府驻牙克石。 1950年5月，政务院批准，察哈尔省的宝昌县、化德县（除第三区外）、多伦县（除2个区外）和沽源县的后新地房子村、诺治村（即太仆寺左旗南部毗连地区）3县2村划归内蒙古自治区察哈尔盟。 1950年7月，内蒙古自治区人民政府批准，科尔沁左翼中旗驻地由架马吐迁至巴彦塔拉。 1951年 1月，满洲里市军政委员会成立，直属东北局和东北军区领导。 4月24日，内蒙古自治区人民政府批准，内蒙古自治区察哈尔盟宝昌县第五区波罗素庙、戴家营、三盖淖、脑包洼、阎油房5个行政村14自然村划归察哈尔省察北专区。 4月7日，政务院批准，设立鄂伦春旗，以喜桂图旗的托扎明苏木及莫力达瓦旗的甘奎、诺敏、多布库尔3苏木为其行政区域。旗政府驻小二沟，由呼纳盟领导。 7月17日，政务院批准，设立通辽市（县级），通辽县城关区为其行政区域。 1952年 东西乌珠穆沁东浩济特联合旗更名为东部联合旗。 撤销西阿巴嘎西阿巴哈纳尔联合旗，东阿巴嘎东阿巴哈纳尔西浩济特联合旗，合并设立西部联合旗。 5月12日，中共中央批准同意中共中央华北局《关于内蒙古与绥远工作关系问题的四项解决办法》。内蒙古自治区人民政府、中共中央内蒙古分局、内蒙古军区一级领导机关，全部迁驻归绥市；绥远省人民政府由政务院和内蒙古自治区人民政府双重领导，但各有重点，省的一般行政事宜和非民族自治区领导重点在中央，辖区内各盟旗民族事务领导重点在内蒙古。 5月31日，内务部批准，撤销鄂伦春旗，设立鄂伦春自治旗。 6月6日，政务院批准，撤销科尔沁右翼后旗，分别并入科尔沁右翼前旗、扎赉特旗。 6月6日，政务院批准，撤销中部联合旗，并入西部联合旗。 6月28日，政务院批准，内蒙古自治区人民政府驻地由张家口市迁至归绥市。 1953年 1月23日，内蒙古自治区人民政府决定，撤销东部呼纳、兴安、哲里木等盟，保留昭乌达盟，合并成立内蒙古东部行政公署。 2月1日，内蒙古东部行政公署在乌兰浩特市成立。 4月1日，内务部批准，撤销呼纳、兴安、哲里木3盟，合并设立内蒙古自治区东部行政公署，昭乌达盟由该公署领导。 5月10日，政务院批准，将通辽、乌兰浩特、海拉尔、满洲里4市升格为地级市。 6月30日，内蒙古自治区人民政府批准，察哈尔盟明安太右联合旗驻地由女子部迁至宝沙岱。 9月4日，内蒙古自治区人民政府批准，将锡林郭勒盟政府所在地贝子庙改称锡林浩特。 9月28日，昭乌达盟的扎鲁特旗划归东部行署直接领导。 10月2日，政务院批准，内蒙古自治区人民政府与绥远省人民政府正式合署办公。 11月1日，内蒙古自治区人民政府与绥远省人民政府执行合署办公。 1954年 喀尔沁左翼后旗人民政府驻地由吉尔嘎郎迁至甘旗卡。 1月7日，内务部批准，集宁专区的固阳县划归乌兰察布盟管辖。 1月11～17日，绥远省一届三次各界人民代表会议在归绥市举行。会议决定绥远省、内蒙古自治区合并，撤销绥远省建制。 1月18日，中央人民政府政务院第204次会议，同意绥远省一届三次各界人民代表会议《关于绥远省、内蒙古自治区合并、撤销绥远省建制的决议的报告》。 1月22日，内蒙古自治区人民政府、绥远省人民政府举行联席会议，通过贯彻《关于绥远省、内蒙古自治区合并，撤销绥远省建制，统一由内蒙古自治区人民政府领导的决议》。 3月5日，内蒙古自治区人民政府批准，撤销正红旗、正黄旗、东四旗中心旗、镶蓝镶红联合旗、陶林县，设立察哈尔右翼前旗、察哈尔右翼中旗、察哈尔右翼后旗；驻地分别为土贵乌拉、科布尔、土木尔台镇。 3月5日，内蒙古自治区人民政府批准，撤销晏江县，设立达拉特后旗，驻塔尔湖镇。 3月5日，内蒙古自治区人民政府批准，撤销归绥县，并入土默特旗。 3月6日，绥远省、内蒙古自治区正式合并，撤销绥远省建制和绥远省人民政府。原绥远省辖区统一由内蒙古自治区人民政府领导。 4月20日，内蒙古自治区人民政府批准，归绥市更名为呼和浩特市。 5月21日，内蒙古自治区人民政府批准，撤销内蒙古自治区东部区行政公署，恢复哲里木盟，将原兴安盟与呼纳盟合并，改为呼伦贝尔盟，盟人民政府设在海拉尔市，辖乌兰浩特、海拉尔、满洲里3市；新巴尔虎左、新巴尔虎右、陈巴尔虎、索伦、额尔古纳、喜桂图、莫力达瓦、阿荣、布特哈、科尔沁右翼前、扎赉特、科尔沁右翼中12旗及鄂伦春自治旗和突泉县。 5月21日，内蒙古自治区人民政府批准，乌兰浩特、海拉尔、满洲里3市改为县级市，划归呼伦贝尔盟领导。 5月21日，内蒙古自治区人民政府批准，通辽市改为县级市，划归哲里木盟领导。 6月19日，中央人民政府批准撤销绥远省，并入内蒙古自治区。 6月19日，中央人民政府批准，撤销伊克昭蒙古族自治区，设立伊克昭盟，盟公署驻东胜。 6月19日，中央人民政府批准，撤销乌兰察布蒙古族自治区，设立乌兰察布盟，盟公署驻固阳。 6月19日，中央人民政府批准，撤销集宁专区，设立平地泉行政区，驻平地泉镇。 6月19日，中央人民政府批准，撤销陕坝专区，设立河套行政区，驻陕坝镇。 1955年 设立包头市回民自治区，以一区东门大街及以北地区为其行政区域。 7月30日，全国人民代表大会一届二次会议决定，撤销热河省，所属的承德市及承德、平泉、青龙、兴隆、滦平、丰宁、隆化、围场8县划归河北省；建昌、凌源、建平、朝阳、北票5县及喀喇沁左旗划归辽宁省；赤峰、乌丹、宁城3县和敖汉、喀喇沁2旗及翁牛特蒙古族自治旗划归内蒙古自治区昭乌达盟。 12月，内蒙古自治区人民政府批准，撤销呼和浩特市回民自治区，设立回民区。 1956年 2月23日，国务院批准，吉林省长岭县的保康镇划归内蒙古自治区科尔沁左翼中旗。 3月9日，国务院批准，撤销翁牛特蒙古族自治旗、乌丹县，设立翁牛特旗。 4月2日，国务院批准，撤销平地泉镇，设立集宁市。以平地泉镇和集宁县的部分地区为其行政区域。 4月3日，国务院批准，设立巴彦浩特市，以阿拉善旗的巴彦浩特镇为其行政区域。 4月3日，国务院批准，撤销巴彦浩特蒙古族自治州，设立巴彦淖尔盟。辖巴彦浩特市、阿拉善旗、额济纳旗、磴口县。 4月3日，国务院批准，甘肃省巴音浩特蒙古族自治州和张掖专区的额济纳自治旗划归内蒙古自治区。 4月3日，国务院批准，撤销额济纳自治旗，设立额济纳旗。 5月15日，内蒙古自治区人民政府批准，撤销包头市一区、二区、回民自治区，设立昆都仑区、东河区、青山区。 5月16日，国务院批准，内蒙古自治区宁城县左杖子村划归辽宁省凌源县。 6月1日，内务部批准，陕西省靖边县巴兔滩乡划归内蒙古乌审旗。 6月1日，国务院批准，昭乌达盟驻地由巴林左旗迁至赤峰镇。 6月1日，国务院批准，翁牛特旗驻地由乌敦套海迁至乌丹乡。 6月14日，国务院批准，撤销东部联合旗，分别设立东乌珠穆沁旗、西乌珠穆沁旗，分别驻王盖庙、喇嘛库伦庙。 6月14日，国务院批准，西部联合旗更名为阿巴嘎旗。 7月20日，国务院批准，科尔沁左翼中旗人民政府驻地由巴彦塔拉迁至保康镇。 9月11日，国务院批准，撤销宝昌县，并入太仆寺旗、正蓝旗、正镶白旗。 9月11日，国务院批准，撤销明安太右联合旗，并入正蓝旗、正镶白旗。 9月11日，国务院批准，太仆寺左旗更名为太仆寺旗。 9月11日，国务院批准，正白镶白联合旗更名为正镶白旗。 9月11日，国务院批准，商都镶黄联合旗更名为商都镶黄旗。 9月11日，国务院批准，太仆寺旗驻地由炮子营迁至宝昌镇。 9月11日，国务院批准，正镶白旗驻地由布尔都庙迁至查汗淖尔。 9月11日，国务院批准，正蓝旗驻地由那日图迁至黄旗大营子。 9月14日，国务院批准，撤销乌兰察布盟的石拐沟矿区，并入包头市、固阳县。 10月16日，国务院批准，河北省围场县太平地乡双敖包自然屯划归内蒙古自治区喀喇沁旗按丹沟乡。 11月，呼和浩特市批准，撤销呼和浩特市庆凯区，并入回民区、玉泉区。 11月20日，设立包头市石拐沟矿区。 1957年 1月1日，呼伦贝尔盟建立10个民族乡。即：布特哈旗达斡尔民族乡、鄂伦春民族乡、额尔古纳旗护林回族乡、莫力达瓦旗巴彦索伦民族乡、杜拉尔索伦民族乡、阿荣旗林音阿索伦民族乡、得力其尔索伦民族乡、新发朝鲜民族乡、科尔沁右翼前旗三合朝鲜民族乡，古城朝鲜民族乡。 1月，锡林郭勒盟二连镇升格为县级建制。 3月8日，自治区党委根据相关少数民族意愿，将索伦、通古斯、雅库特人恢复原称，统称为鄂温克族，并实行民族区域自治。同时发出通知，要求今后凡口头称呼、文字宣传、公文，布告等一律使用“鄂温克”名称。 4月2日，国务院批准，撤销集宁县，并入集宁市、察哈尔右翼前旗、察哈尔右翼后旗、兴和县。 7月19日，二连镇改称二连浩特。 7月20日，国务院批准，辽宁省彰武县十家子乡的敖海屯划归内蒙古自治区库伦旗。 1958年 内蒙古自治区人民委员会批准，杭锦后旗旗驻地由三道桥迁至陕坝镇。 拉特前旗政府移驻西山嘴，暂驻扒子补隆。 1958年中国政府同意，在内蒙古自治区巴彦淖尔盟乌拉特中后联合旗境内，划出4200平方千米的草场，供蒙古人民共和国南戈壁省的牲畜过冬、春。 4月2日，国务院批准，撤销平地泉行政区，所属的兴和、丰镇、凉城、和林格尔、清水河、托克托、萨拉齐、武川、武东，卓资10县和察哈尔右翼后旗、察哈尔右翼中旗、察哈尔右翼前旗、土默特旗、集宁市划归乌兰察布盟，盟公署由固阳县迁驻集宁市。 4月2日，国务院批准，撤销河套行政区，所属的临河、狼山、五原、安北4县，达拉特后旗、杭锦后旗及陕坝镇划归巴彦淖尔盟。 4月2日，国务院批准，乌兰察布盟的乌拉特前旗，乌拉特中后联合旗划归巴彦淖尔盟。 4月2日，国务院批准，巴彦淖尔盟盟公署由巴彦浩特市迁驻磴口县的三盛公镇。 4月2日，国务院批准，撤销狼山县、陕坝镇，并入杭锦后旗。 4月2日，国务院批准，撤销安北县，并入乌拉特前旗。 4月2日，国务院批准，撤销萨拉齐县，将原萨拉齐县西部的杨圪楞、鄂尔圪逊、沙尔沁、大巴拉盖等4个乡划归包头市，其余地区均划归土默特旗，旗政府移驻原萨拉齐县县城。 4月2日，国务院批准，撤销武东县，将原武东县北部的后哈卜泉、乌兔沟、英兔、库伦图、三元井、活佛滩、忽鸡图7乡划归四子王旗；东部的蒙古寺、上西河子、大滩、大井、广益隆、麻迷兔、头号、阳坡子、义合隆9乡划归察哈尔右翼中旗；将南部的吉庆营、东河子、大同营子、旗下营、红召、巨宝庄、福兴、速力图8乡划归卓资县；将西部的厂汗此老、高家沟、西河子、东梁底4乡划归武川县。 4月2日，国务院批准，撤销乌兰察布盟的白云鄂博办事处，设立包头市白云矿区。 4月21日，国务院批准，乌兰察布盟行政机关由固阳县迁至集宁市。 5月29日，国务院批准，撤销索伦旗，设立鄂温克族自治旗（8月1日正式成立）。 5月29日，国务院批准，撤销莫力达瓦旗，设立莫力达瓦达斡尔自治旗（8月15日正式成立）。 6月3日，国务院批准，苏尼特右旗驻地由温都尔庙迁至赛汗塔拉镇。 7月5日，国务院批准，撤销达拉特后旗，并入五原县。 7月5日，国务院批准，固阳县由乌兰察布盟划入包头市，改为固阳区。 9月5日，国务院批准，撤销巴彦浩特市，并入阿拉善旗。 9月26日，国务院批准，撤销察哈尔盟，所属各旗县划归锡林郭勒盟，盟公署设在锡林浩特。 10月4日，自治区人民委员会发出《关于国务院决定撤销巴彦浩特市的通知》，决定原巴彦浩特市的行政区域全部划归阿拉善旗管辖。 10月20日，国务院批准，撤销赤峰县，设立赤峰市（县级）。 11月21日，国务院批准，撤销通辽县，并入通辽市。 11月21日，国务院批准，撤销扎萨克旗、郡王旗，合并设立伊金霍洛旗。 1959年 额济纳旗驻地由建国营迁至达来湖波镇。 1月5日，国务院批准，鄂伦春自治旗驻地由小二沟迁至阿里河。 1960年 1月7日，国务院批准，撤销突泉县，并入科尔沁右翼中旗，驻地由高力板迁至突泉镇。 1月7日，国务院批准，撤销磴口县，设立巴彦高勒市（县级），以原磴口县的三盛公镇为中心，北至艾家湾子，南至二十里柳子、小李店的北边，东临黄河，西靠防沙林带的区域为其行政区域，磴口县其他地区并入阿拉善旗、鄂托克旗。三盛公镇随磴口县同时撤销。 4月3日，内蒙古自治区人民委员会批准，撤销包头市郊区，并入东河、青山、昆都仑、石拐矿4区。 6月，内蒙古自治区人民委员会批准，土默特旗驻地由萨拉齐镇迁至察素齐镇。 7月14日，国务院批准，乌兰察布盟的土默特旗划归呼和浩特市。 7月14日，国务院批准，撤销乌拉特前旗，并入包头市、乌拉特中后联合旗。 9月13日，国务院批准，商都镶黄旗更名为镶黄旗。 9月13日，国务院批准，撤销化德县，并入商都镶黄旗，驻地由新宝力格迁至化德镇。 1961年 内蒙古自治区人民委员会批准，额尔古纳旗驻地由三河迁至根河。 4月22日，国务院批准，撤销阿拉善旗，阿拉善左旗、阿拉善右旗。阿拉善右旗辖巴音温都尔等5个公社，阿拉善左旗辖巴彦浩特镇和嘉尔格拉赛汗等11个公社，其余地区划归巴彦高勒市和乌达镇管辖。 5月31日，内蒙古自治区人民委员会发出《关于设立阿拉善左、右两旗，撤销阿拉善旗决定的通知》。 7月9日，国务院批准，设立乌达市，以阿拉善左旗的乌达镇的行政区域为其的行政区域。 7月9日，国务院批准，设立海勃湾市，以鄂托克旗的卓资山（桌子山）矿区为其行政区域。 7月9日，国务院批准，撤销包头市固阳区，设立固阳县。 1962年 3月7日，内蒙古自治区人民委员会批准，科尔沁右翼中旗驻地由突泉镇迁至白音胡硕（黑大庙）。 3月7日，国务院批准，河北省商都县划归内蒙古自治区乌兰察布盟。 10月20日，国务院批准，设立突泉县，以原突泉县并入喀尔沁右翼中旗的地区为其行政区域 10月20日，国务院批准，设立赤峰县，以原赤峰县并入赤峰市的地区和翁牛特旗部分地区为其行政区域。 1963年 镶黄旗驻地由化德镇迁至新宝力格。 3月31日，设立包头市郊区，以新城、麻池、古城湾、河东、前明、国庆、哈林格尔、哈业胡同、沙尔沁、兴胜、金巴兔、哈业脑包、后营子等14个公社为其行政区域。 3月31日，国务院批准，呼和浩特市的土默特旗划归乌兰察布盟。 4月13日，国务院批准，设立化德县，以原化德县并入镶黄旗的地区为其行政区域。 7月31日，内蒙古自治区人民委员会第27次全体（扩大）会议决定，设立阿巴哈纳尔旗，以阿巴嘎旗和西乌珠穆沁旗的锡林浩特镇、阿尔山保力格公社、潮格乌拉牧场、军营牧场、一、二、六队、毕力格牧场等地区为其行政区域。 10月23日，国务院批准，设立阿巴哈纳尔旗，以阿巴嘎旗和西乌珠穆沁旗的锡林浩特镇、阿尔山保力格公社、潮格乌拉牧场、军营牧场、一、二、六队、毕力格牧场等地区为其行政区域。 11月17日，国务院批准，包头市的包拉前旗划归巴彦淖尔盟。 11月17日，国务院批准，包头市的固阳县划归乌兰察布盟。 1964年 7月20日，国务院批准，设立通辽县，以通辽市的郊区除红星公社以外的地区为其行政区域，驻通辽市。 7月20日，国务院批准，撤销巴彦高勒市，设立磴口县，驻巴彦高勒镇. 7月20日，国务院批准，撤销乌兰浩特市，并入科尔沁右翼前旗。 8月21日，内蒙古自治区人民委员会批准，阿拉善右旗人民政府驻地由雅不赖迁至额肯呼都格（由上井子更名）。 10月，内蒙古鄂伦春自治旗的加格达奇镇划归黑龙江省大兴安岭特区。 1965年 2月8日，内蒙古自治区与甘肃省召开座谈会，就内蒙古自治区巴彦淖尔盟的阿拉善左旗、阿拉善右旗、额济纳旗同甘肃省武威、张掖、酒泉专区的古浪、武威、民勤、永昌、临泽、肃北各县争议地区的行政界线达成了协议。 3月27日，国务院批准，撤销土默特旗，分别设立土默特左旗、土默特右旗. 9月22日，国务院批准，呼伦贝尔盟的科尔沁右翼中旗划归哲里木盟。 11月29日，国务院批准，伊金霍洛旗驻地由新街镇迁至阿腾席连。 1966年 1月18日，国务院批准，设立二连浩特市，以苏尼特右旗的部分地区为其行政区域。 1月18日，国务院批准，撤销额尔古纳旗，分别设立额尔古纳左旗、额尔古纳右旗，分别驻根河、三河镇。 1967年 内蒙古自治区革命委员会批准，呼和浩特市玉泉区、新城区、回民区更名为向阳区、东风区、红旗区。 1968年 1月10日，哲里木盟革命委员会成立。 1月28日，昭乌达盟革命委员会成立。 2月13日，中共内蒙古自治区革命委员会核心小组成立。 2月20日，包头市革命委员会成立。 1969年 7月5日，中央批准，内蒙古自治区巴彦淖尔盟的阿拉善右旗、额济钠旗划归甘肃省。 7月5日，中央批准，内蒙古自治区的昭乌达盟划归辽宁省。 7月5日，中央批准，内蒙古自治区的阿拉善左旗和阿拉善右旗的巴音诺尔、乌力吉、塔木素、阿拉腾敖包、松布尔公社划归宁夏回族自治区。 7月5日，中央批准，内蒙古自治区哲里木盟及所属的通辽市、通辽县、开鲁县、科尔沁左翼中旗、科尔沁左翼后旗、科尔沁右翼中旗、奈曼旗、库伦旗、扎鲁特旗和呼伦贝尔盟的突泉县、科尔沁右翼前旗划归吉林省。 7月5日，中央批准，内蒙古自治区的呼伦贝尔盟（除突泉县、科尔沁右翼中旗外）划归黑龙江省。 11月，中央批准，巴彦淖尔盟革命委员会驻地由磴口县迁至临河县。 12月19日，中共中央发布《关于内蒙古实行分区全面军管的决定》，责成北京军区对内蒙古自治区实行分区全面军管乌兰察布盟的二连浩特市、苏尼特右旗划归锡林郭勒盟。 1970年 10月3日，国务院批准，乌兰察布盟的土默特左旗，托克托县划归呼和浩特市. 10月3日，国务院批准，乌兰察布盟的固阳县，土默特右旗划归包头市。 10月30日，中央、国务院批准，设立潮格旗，以乌拉特中后联合旗的部分地区为其行政区域。 1971年 察哈尔右翼后旗人民政府驻地由土木尔台迁至白音察干镇。 1972、1973、1974年 无变更。 1975年 8月30日，国务院批准，撤销乌达市，海勃湾市，设立乌达市（地级）。 1976年 无变更。 1977年 12月30日，内蒙古自治区人民政府批准，设立包头市建华矿区，以青山区的的部分地区为其行政区域。 1978年 10月，呼和浩特市人民政府批准，呼和浩特市红旗区恢复原名回民区。 1979年 呼和浩特市人民政府批准，呼和浩特市东风区恢复原名新城区。 5月30日，中央、国务院批准，甘肃省的阿拉善右旗和额济纳旗划归内蒙古自治区。 5月30日，中央、国务院批准，宁夏回族自治区的阿拉善左旗划归内蒙古自治区。 5月30日，中央、国务院批准，辽宁省的昭乌达盟划归内蒙古自治区。 5月30日，中央、国务院批准，吉林省哲里木盟（通辽市、通辽县、开鲁县、科尔沁右翼中旗、扎鲁特旗、科尔沁左翼中旗、奈曼旗、库伦旗、科尔沁左翼后旗）及白城地区的突泉县、科尔沁右翼前旗划归内蒙古自治区。 5月30日，中央、国务院批准，黑龙江省的呼伦贝尔盟及大兴安岭地区的鄂伦春自治旗、莫力达瓦达斡尔族自治旗划归内蒙古自治区。 12月13日，自治区人民政府批准，设立乌海市海勃湾区、乌达区、海南区。 12月12日，国务院批准，设立阿拉善盟，辖原巴彦淖尔盟的阿拉善右旗、阿拉善左旗、额济纳旗，驻阿拉善左旗的巴彦浩特镇（1980年4月1日实施）。 1980年 3月，呼和浩特市人民政府批准，呼和浩特市向阳区恢复原名玉泉区。 5月8日，自治区人民政府批准，乌兰察布盟的二连浩特市、苏尼特右旗划归锡林郭勒盟。 7月18日，自治区党委批准，设立扎赉诺尔矿区。 7月26日，国务院批准，设立乌兰浩特市，以科尔沁右翼前旗的部分地区为其行政区域。 7月26日，国务院批准，设立兴安盟，辖呼伦贝尔盟的突泉县、扎赉特旗、喀尔沁右翼前旗和哲里木盟的科尔沁右翼中旗（10月1日成立）。 8月18日，国务院批准，设立鄂托克前旗，以鄂托克旗的布拉格、毛盖图、马拉迪、查干陶勒盖、吉拉、珠和、三段地、二道川、城川、芒哈图等10个人民公社为其行政区域，驻敖勒召其。 11月1日，自治区人民政府批准，撤销包头市建华矿区，并入青山区。 1981年 8月21日，国务院批准，潮格旗更名为乌拉特后旗。 8月21日，国务院批准，乌拉特中后联合旗更名为乌拉特中旗。 1982年 12月，自治区人民政府决定，阿巴哈纳尔旗改称阿巴嘎纳尔旗。 1983年 10月10日，国务院批准，赤峰市升为地级市。 10月10日，国务院批准，撤销昭乌达盟，所属的宁城县、林西县、喀喇沁旗、敖汉旗、翁牛特旗、巴林右旗、巴林左旗、阿鲁科尔沁旗、克什克腾旗划归赤峰市。 10月10日，国务院批准，撤销赤峰县，并入赤峰市。 自治区人民政府批准，设立赤峰市红山区、元宝山区、郊区。 10月10日，国务院批准，撤销喜桂图旗，设立牙克石市。 10月10日，国务院批准，撤销布特哈旗，设立扎兰屯市。 10月10日，国务院批准，撤销阿巴哈纳尔旗（阿巴嘎纳尔旗），设立锡林浩特市。 10月10日，国务院批准，撤销东胜县，设立东胜市。 1984年 10月20日，自治区人民公社体制改革工作全部完成。共建立苏木、乡、镇政府1553个，其中苏木政府431个，乡政府897个，民族乡政府13个，乡镇政府212个。 12月11日，国务院批准，国务院批准，撤销临河县，设立临河市。 1985年 11月9日，国务院批准，设立霍林浩特市，以扎鲁特旗的霍林河办事处为其行政区域，驻珠斯花镇。 1986年 7月21日，国务院批准，撤销通辽县，并入通辽市。 1987年 5月13日，国务院批准，内蒙古自治区阿拉善盟阿拉善左旗与甘肃省景泰县行政区进行划界。 1988、1989年 无变更。 1990年 11月15日，国务院批准，撤销丰镇县，设立丰镇市。 11月，内蒙古自治区人民政府与吉林省人民政府就划定两省区界线问题达成协议。 1991、1992年 无变更。 1993年 5月3日，民政部民行批〔1993〕89号文，批复将赤峰市郊区更名为松山区。 1994年 4月28日，国务院批准，撤销额尔古纳左旗，设立根河市。 7月13日，国务院批准，撤销额尔古纳右旗，设立额尔古纳市 1995年 11月21日，国务院批准，将乌兰察布盟和林格尔县、清水河县划归呼和浩特市。 1996年 5月18日，国务院批准，将乌兰察布盟武川县划归呼和浩特市管辖。 5月18日，国务院批准，将乌兰察布盟达尔罕茂明安联合旗划归包头市管辖。 6月10日，国务院批准，设立阿尔山市，以科尔沁右翼前旗部分区域为阿尔山市的行政区域。 8月30日，国务院批准，准格尔旗人民政府驻地由沙圪堵镇迁驻薛家湾镇。 1997、1998、1999年 无变更。 2000年 5月14日，国务院国函〔2000〕42号文批准，将呼和浩特市郊区更名为赛罕区。同时对呼和浩特市市辖区的行政区域进行调整。 调整后各市辖区的行政区域如下： 1、新城区：辖锡林郭勒北路、新城东街、新城西街、海拉尔东路4个街道办事处，中山东路街道办事处位于健康街以北、呼伦贝尔南路以西 的部分，东风路街道办事处和迎新路街道办事处位于东风路以北的部分，以及从原郊区划入的毫沁营、保合少、小井3个乡，巴彦镇的塔利、生盖营、讨思浩、榆树沟、姚家湾、古路板、甲兰板、野马图8个村委会，巧报乡的府兴营、麻花板、新城、三合村4个村委会。区人民政府驻新城西街。 2、回民区：辖通道街、中山西路、环河街、新华西路、光明路、海拉尔西路6个街道办事处，以及从原郊区划入的攸攸板乡，西菜园乡的金龙居委会和青山、厂汉板、倘不浪、西龙王庙、四合兴、什拉门更、小府、塔布板、孔家营9个村委会。区人民政府驻通道南街。 3、玉泉区：辖小召、大南街、兴隆巷、长和廊、石羊桥东路5个街道办事处，以及从原郊区划入的桃花、小黑河2个乡，西菜园乡的西霞园、 巴彦乌素、芦花庄、落雁、辛兴5个居委会和范家营、西瓦窑、五里营、南八里庄、西菜园、南茶坊、碱滩、大围困、南营子、西水磨、辛辛板、小黑河、沟子板13个村委会。区人民政府驻公园西路。 4、赛罕区：辖原郊区的太平庄、西把栅、章盖营3个乡和榆林、金河、黄合少3个镇，巧报乡的东瓦窑、后巧报、双树、小台什、帅家营、大台什、桥靠、前巧报8个村委会，巴彦镇的商业街居委会和黑土凹、后罗家营、乔家营、郭家营、坝堰、滕家营、罗家营7个村委会，以及从新城区划入的人民路、大学西路2个街道办事处，中山东路街道办事处位于健康街、乌兰察布西路以南的部分，东风路街道办事处和迎新路街道办事处位于东风路以南的部分。区人民政府驻巧报乡。 2001年 2月26日，民政部批准: 1、撤销内蒙古自治区伊克昭盟和县级东胜市，设立地级鄂尔多斯市。市人民政府驻新设立的东胜区。 2、鄂尔多斯市设立东胜区，以原县级东胜市的行政区域为东胜区的行政区域。区人民政府驻宝日陶亥西街。 3、鄂尔多斯市辖原伊克昭盟的伊金霍洛旗、乌审旗、达拉特旗、准格尔旗、杭锦旗、鄂托克前旗、鄂托克前旗和新设立的东胜区 10月10日，民政部批准: 1、撤销内蒙古自治区呼伦贝尔盟和县级海拉尔市，设立地级呼伦贝尔市。市人民政府驻新设立的海拉尔区胜利大街。 2、呼伦贝尔市设立海拉尔区，以原县级海拉尔市的行政区域为海拉尔区的行政区域。区人民政府驻广场路。 3、呼伦贝尔市辖原呼伦贝尔盟的阿荣旗、陈巴尔虎旗、新巴尔虎左旗、新巴尔虎右旗、莫力达瓦达斡尔族自治旗、鄂伦春自治旗、鄂温克族自治旗和新设立的海拉尔区。原呼伦贝尔盟的满洲里市、牙克石市、扎兰屯市、额尔古纳市和根河市由内蒙古自治区直辖。 2002年 无变更。 2003年 7月8日，民政部民函〔2003〕135号文批准，科尔沁右翼前旗人民政府驻地由乌兰浩特市市区迁至科尔沁右翼前旗大坝沟镇。 12月1日，国务院国函〔2003〕121号文批准，撤销巴彦淖尔盟，设立地级巴彦淖尔市： 1、撤销巴彦淖尔盟和县级临河市，设立地级巴彦淖尔市。市人民政府驻新设立的临河区新华东街。 2、巴彦淖尔市设立临河区。以原县级临河市的行政区域为临河区的行政区域，区人民政府驻庆丰东街。 3、巴彦淖尔市辖原巴彦淖尔盟的乌拉特前旗、乌拉特中旗、乌拉特后旗、杭锦后旗、五原县、磴口县和新设立的临河区。 12月1日，国务院国函〔2003〕122号文批准，撤销乌兰察布盟，设立地级乌兰察布市： 1、撤销乌兰察布盟和县级集宁市，设立地级乌兰察布市。市人民政府驻新设立的集宁区乌兰察布大街。 2、乌兰察布市设立集宁区。以原县级集宁市的行政区域为集宁区的行政区域，区人民政府驻恩和路。 3、乌兰察布市辖原乌兰察布盟的四王子旗、察哈尔右翼前旗、察哈尔右翼后旗、察哈尔右翼中旗、化德县、商都县、兴和县、卓资县、凉城县和新设立的集宁区。原乌兰察布盟的县级丰镇市由自治区直辖。 2004年以后，基本无变更。 阿拉善盟行政区划图 乌海市行政区划图 巴彦淖尔市行政区划图 包头市行政区划图 呼和浩特市行政区划图 鄂尔多斯市行政区划图 乌兰察布市行政区划图 锡林郭勒盟行政区划图 赤峰市行政区划图 通辽市行政区划图 兴安盟行政区划图 呼伦贝尔市行政区划图

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项修炼》 大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。