在各种技术大会的架构分享中，经常听到这样一句话：“一切忽视业务的架构设计都是耍流氓”。基础设施建设似乎正是“与商业无关”的流氓行为。基础设施不直接实现业务功能。当购物车系统出现故障时，没有人会关心是Redis集群不稳定还是配置中心连接数过高。因此，只有技术部门才能意识到这方面的工作有多么重要，但往往在与业务需求的PK中吃亏，成为房间里的大象。那天。什么是基础设施？基础设施与业务无关吗？电子商务系统的特点是什么？需要什么样的基础设施？我国刺激经济的一大举措就是搞基建，俗称“铁公基”。几年前，有人说云计算是未来互联网的基础设施。大型系统需要更加统一、专业、可靠的组件、模块、框架和平台，以保证整个系统高效、可控、可信。电子商务，尤其是B2C电子商务，不同于门户、社交、游戏、工具。它本质上是一个以交易为中心的系统，需要每天7*24小时提供服务。它涉及金钱，高度敏感，并且具有很强的相关性。很多功能往往堆积如山（大部分只有上下），系统复杂，边界模糊，技术债积压。它使用了多种异构技术，不易维护，缺乏文档，还有各种历史包袱。摊子越来越大了。根据熵增原理，管理成本越来越高，难以调整和优化。基础设施服务于整个系统，必然受到行业特性的影响。电子商务的基础设施一般包括以下几个部分。为什么要建设基础设施？原因有四：1、打好基础，事半功倍。IT技术的价值在于它的重用。完善的基础设施将保证系统的快速演进，高效响应业务需求。2、提高系统的可控性系统越复杂，规模越大，越难管理。需要系统的手段使之成为一个有机的整体。3、业务代码和框架隔离，平台人员流失率高，新手比例大。提供框架和平台，可以让新手只实现业务代码，充分合理利用人力资源，提高系统稳定性。4.减少技术债务，提高管理效率，建设基础设施，通过技术手段降低债务风险。完善的基础设施可以降低沟通成本，节省时间，提高管理效率。如前所述，基础设施建设难以重视。如何实施？1、顺应潮流，拨乱反正。如果你关注度高，或者某个领域的技术成为热点，你应该牢牢抓住这样的机会，顺势而为，实施适合自己的、贴近行业主流的解决方案，做想要什么，没有太多的纠结。2、自下而上，从点到面基础设施建设有其规律，一般是自下而上，但逐层全面实现需要投入大量资源，所以先布局点，再用点作为支撑扩展成一个面更可行，适当的重复构造是可以接受的。3、抓住痛点，有备无患。既然不能按部就班，就必须把好钢用在刀刃上，集中优势力量，攻坚克难。识别关键问题需要全局观，尽可能了解各方面的情况，找到痛点。痛点不一定是难点，大部分问题都有解决方案。如何解决它们的方向非常明确。提前做好调研，等待机会。4.弥补任何时候都不晚。理想的情况是凡事都往前走。理论上资源投入最少，风险最高，利润最高。但是，由于种种原因，总有漏洞不能及时填补，出现问题是很正常的，及时处理也是非常必要的，以免进一步恶化。接下来，将从三个方面介绍当当网的基础设施建设经验。首先是部署运维方面。现在很多公司都在搞多机房容灾。常见的标准是两地三中心，但往往变成两地三机房。系统跨机房部署，备份不足。机房之间的网络通信问题直接影响系统的可用性，多个机房反而成了不稳定因素。请问有多少公司真正进行过灾备切换演练？有多少人敢在系统有问题的时候拍着胸脯说系统没问题？我们应该做什么？，如果技术实力足够，还是多干点活儿好。现在很多创业公司甚至大公司都在走向云端，使用公有云或者自建私有云。然而，公有云真的靠谱吗？一旦出现问题，造成业务损失，公有云会赔偿吗？或者您可以跨云部署？这不是给自己添麻烦吗？本来用公有云就是为了省钱省事，你牛逼到可以简单的搭建一个私有云，但是私有云真的能hold住吗？您是否有足够的技术人员及时处理各种问题？技术复杂，一切都由软件定义，需要更强的运维能力。总之，尽量简化系统部署架构，多做演练，不要迷信所谓的高科技。归根结底，这一切都需要人，人才是最宝贵的财富。让我们谈谈数据库管理。数据库本身就是一个管理系统。但是大型系统有几百个甚至上千个数据库是很正常的，根据场景可能会使用各种类型的数据库，从MySQL、SQLServer、Oracle到MongoDB、Greenplum等等。数据库表结构是否合理？数据同步、备份、数据库运行是否正常，数据库访问权限的管理和分配需要系统管理。搭建数据库管理平台可以解决这些问题，甚至可以通过系统化的手段进一步发现问题，比如哪些表空间增长过快需要扩容，比如一些相同含义的字段是否定义类型和长度不一致。与数据库管理平台类似，Redis缓存集群也需要这样一个资源管理平台，而Redis本身管理功能有限，是分布式集群，需要平台管理。由于使用姿势不当等问题，Dang这两年在Redis的使用中经历了很多坑。为避免各团队重蹈覆辙，2016年初上线Redis资源管理平台，系统化管理缓存资源、节点、统一版本。开发者无需关心底层基础设施，简化运维复杂度，提供统一、系统的运维监控和管理。当然，还有一点就是更合理地分配资源，充分利用资源。系统监控的重要性无需赘述。先说说这里的选择吧。当当网用的是Nagios做系统监控，后来改成Zabbix。作为主流的开源产品，从选型的角度来看可能并没有太大区别。监控制度是最重要的，最重要的是落实到位。它需要有人来支持和推广。需要实际应用，真正监控每一台服务器。其次是基础管理。说来可笑，很多互联网公司在技术部门的信息化建设上投入很少。很多工程师以做业务系统和解决分布式、高并发、大规模数据问题为荣，不屑于开发基础管理系统。结果，这导致了技术团队协作效率低下和管理混乱。经过几年的建设，当当网基本建立了贯穿产品生命周期的基础管理体系，涵盖项目管理、自动部署、监控告警、问题跟踪等。PDLC是一个项目管理系统。通过系统，您可以发起需求、跟踪进度、分配任务、查看人力资源使用情况，对当前团队项目执行情况一目了然。电子看板具备敏捷开发功能，可以很好地支持每天的站会，比实体看板更具技术性。有系统总比没有好。有些公司非常大，但甚至没有项目管理系统。不难想象，问题一定很多。既然可以依靠人了，项目经理此刻就觉得自己是个悲剧。系统太多了，业务也大了，不管是不是微服务，在上千台服务器上部署应用实例都是一个大动作，却是我们每天都要面对的家常便饭。如果我们靠年轻的运维工程师写脚本执行，老板们肯定坐不住他们的位子。人虽然宝贵，但也是最不可靠的，稳定性比机器差很多。因此，必须有一个自动化部署平台，支持从开发到测试再到生产的各种环境下的编译检查、版本管理、备份、灰度、回滚。当当网的自动化运维部署平台叫盘古，2015年获得了总裁表彰奖。我上面说的是系统监控、应用监控、业务监控同等重要。监控的完备程度反映了系统运维管理的水平。Radar是检测监控系统，APIMonitor是服务质量监控系统。从下图的统计对比可以看出，监控数据量明显增加。这就是拥有工具的好处，想用就用，传播快。接下来要解决的是监控更多的维度，实现监控系统的自我监控，根据监控数据提供趋势分析和关联分析，准确报警，甚至防患于未然。无论是告警还是产品系统问题，都需要有人跟踪解决。Tracker就是这样一个问题跟踪系统。通过该系统，可以避免问题因转发而丢失在邮件服务器中。可分级，跟踪问题解决路径和时效性，并可随时间自动升级。下图是Tracker系统订单的实时刷新显示。Radar系统中也有类似的实时显示，通过红绿灯更直观的显示应用异常情况。这类系统的难点在于问题的分类和分级。需要和各部门的用户进行沟通，结合系统的现状，逐步优化体验，提高效率。***是技术架构。在技??术架构上，当当网的架构部门经历了一个自下而上、由点到面、从组件到框架再到平台的渐进过程。2014年SOA选型使用Dubbo。考虑到当当网的系统异构性和支持HTTP调用的需要，二次开发并开源了DubboX，证明了开发基础组件的能力。2015年开发应用框架DDFrame，嵌入DubboX和TBSchedule，自研RDB模块，并在多个系统中应用。后来又开发了分布式弹性作业调度框架Elastic-Job和轻量级数据库中间件Sharding-JDBC，也都开源了。2016年，在Elastic-Job的基础上，结合Mesos开发了Elastic-Job-Cloud。这已经是一个智能作业云平台，采用容器领域最新技术，实现自动化资源管理和调度。减少服务器资源浪费，体现云计算的价值。以上组件开源地址如下，欢迎关注使用，更欢迎参与开发。https://github.com/dangdangdotcom/dubboxhttps://github.com/dangdangdotcom/elastic-jobhttps://github.com/dangdangdotcom/sharding-jdbc***三句话简单总结：1.使用automatic代替manual2.用小系统带动大团队3.用基础平台支撑上层应用，所以没有新意，真相不为人所知。最重要的是把它做好，用好它才有价值。【本文为专栏作家“史海峰”原创稿件。转载请通过作者微信联系授权公众号《IT相声》】点此查看作者更多好文
