• 叁叁肆2018-11-13
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 2.2.2 Docker 镜像及操作 Docker 包含 3 个基本概念,分别是镜像(Image)、容器(Container)和仓库(Repository)。 镜像是 Docker 运行容器的前提,仓库是存放镜像的场所,可见镜像更是 Docker 的核心。 镜像作为 Docker 最突出的创新之一,它变革了软件交付标准。理解镜像,对理解整个 Docker 的生命周期非常重要。本节将围绕镜像这一核心概念,简明扼要地介绍镜像的各种 操作,带你玩转 Docker 镜像。 注:对镜像应用感兴趣的读者,还可以查看网易云推出的“玩转
  • 叁叁肆2018-11-13
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 2.1.5 代码版本管理 设想这样的场景,你对代码做了一些变更,上线后发现代码有问题无法正常运行怎么 办?你肯定会想赶紧回滚到原来的代码,如果没有代码版本控制的工具,就很麻烦。 代码版本管理系统是一种可以帮助开发团队管理代码变更的工具,它会跟踪团队成 员对代码的每一次修改。如果发现变更的代码有问题,开发者可以回滚代码,并且可以与 之前的代码对比,找出问题所在,尽量减小对整个团队成员的影响。对于开发团队来说, 代码是最重要的资产,代码版本管理工具可以避免人为或其他原因导致的代码丢失或文件 损坏。 1. 代码管理工具 代
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 2. Java 语言的框架选型 下面我们选择最普遍的一种业务类型,也就是使用 Java 语言做 Web 开发,来说明如何 进行框架选型。 控制反转及依赖注入  Java 是一门面向对象的编程语言,我们在应用系统设计的时候,往往也会采用面向对 象的方式来设计。在使用面向对象的方式来设计系统实现的时候,我们面对的业务逻辑,往往涉及两个或是更多的类通过彼此的合作来实现,这使得每个对象都需要获取或者实例 化与其合作的对象。如果这个过程要靠对象自身主动装配的话,就会导致代码高度耦合并 且难以维护和调试。当我们更新了某一个模块的
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 3.2 架构实践 在确定好技术选型后,就进入具体的实践阶段。本节主要介绍在实践阶段如何快速迭 代开发、快速交付部署、实现初步的高可用。同时我们的实践从一开始就要注意安全风险, 避免写出有安全漏洞的代码。 3.2.1 快速迭代  在初创期,一般业务不是很稳定,往往会不停地增加新功能。因此,这也要求我们的 应用能够满足快速迭代的需求。 为了快速地进行功能的迭代,除了在需求管理和团队沟通优化上做足文章外,对于业 务功能的具体实践者,也就是我们的开发人员来说,无非就是在接到需求,理解需求的情 况下,能够快速完成功能的开发
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 3.1.2 结构化数据存储 数据是互联网业务最核心的价值,管理数据是互联网应用最重要的功能。在电商业务 场景中,一次会员购买商品的行为,首先涉及商品数据、会员数据的查询,会员点击购买 后,生成订单数据,会员支付成功后,又会涉及订单数据的更新。要实现高效的数据管理, 数据存储是关键,因为数据的存储方案决定了数据的访问方式及访问效率。 电商业务涉及非常多的数据,按照数据结构,我们可以分为结构化数据和非结构化数 据。在电商业务场景中,每一个商品都拥有编号、名称、品牌、货源地、分类等固定的属 性,每个属性都有明确的数据类型和长度约束,例如商品名
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 当我们有了一个应用构想的时候,往往需要快速实现一个原型进行验证及试错。在开 始阶段,应用的业务方向调整比较频繁,此时,我们更多是考虑一个应用基本功能的实现, 以及能否快速迭代以跟上业务方向的调整,实现一个应用的快速成长,并且在实践过程中 尽可能做到为后续的架构升级做好铺垫。 在应用的初创阶段,访问量并不大,一个比较基础的单体架构的系统足以支撑起整个 业务。因此,本章我们不涉及服务拆分、服务化这些内容,而是从做出一个完整的系统出 发,主要的任务是完成基本的业务需求,这些需求包括:选择合适的技术栈;能够快速进 行功能的迭代开发,做好基本
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 3.3.3  操作系统监控 一般情况下,通过应用进程状态我们可以大致判断应用是否正常,如果在某些场景下, 单纯依赖应用进程数据无法判断时,就需要依赖操作系统的一些监控数据来做参考。 操作系统提供对运行硬件资源的封装,从互联网应用的角度看,一般需要关注如下子 系统的基础监控:CPU、内存、磁盘及网络等。这几个子系统之间相互影响,一个子系统 出问题可能会影响其他几个子系统正常工作。 CPU  CPU 使用率情况和使用它的资源密切相关。系统内核调度器的主要职责是调度两种不 同的资源:线程及中断。调度器针对不同的资源有不同
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.1.3 全文检索 搜索,是用户获取信息的主要方式。在日常生活中,我们不管是购物(淘宝)、吃饭(大 众点评、美团网)还是旅游(携程、去哪儿),都离不开搜索的应用。搜索几乎成为每个网 站、APP 甚至是操作系统的标配。在用户面前,搜索通常只是展示为一个搜索框,非常干 净简洁,但它背后的原理可没那么简单,一个框的背后包含的是一整套搜索引擎的原理。 假如我们需要搭建一个搜索系统为用户提供服务,我们又需要了解什么呢?  1. 基本原理  首先,我们需要知道全文检索的基本原理,了解全文检索系统在实际应用中是如何工
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.1.4 日志收集 日志,一组随时间增加的有序记录,是开发人员最熟悉的一种数据。通常,日志可以 用来搜索查看关键状态、定位程序问题,以及用于数据统计、分析等。  日志也是企业生产过程中产生的伟大财富。日志可以用来进行商业分析、用户行为判 断和企业战略决策等,良好地利用日志可以产生巨大的价值。所以,日志的收集不管是在 开发运维还是企业决策中都十分重要。 1. 第三方数据收集服务 在日志收集领域内,目前已经存在了种类繁多的日志收集工具,比较典型的有:rsyslog、 syslog-ng、Logstash、F
  • 叁叁肆2018-11-14
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 3.3 应用监控 应用经过努力,开发完成所有的功能并成功上线,但上线成功是不是终点?显然不是, 我们的应用需要长期稳定地服务客户,而这就需要监控系统的支持。监控系统可以对关键 资源(比如服务)或者应用数据进行持续的监控,并且在监控对象发生异常的时候及时发 送报警,方便开发人员或运维人员快速处理问题,保证应用稳定运行。 在初创阶段,团队的主要精力应该还是以产品功能为主,而应用监控的主要目的是保 证我们的产品能够正常服务用户,如果出现故障,能够及时发现并恢复。应用监控以应用 进程的状态为主,但应用进程又受限于服务器资源,当服务
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.2.4 后端系统扩展 后端系统,一般指用户接入端(Web 系统、长连接服务器)和各种中间件之后的后台系 统。在这一阶段,最重要的后端系统就是两种,缓存服务和数据库服务。下面,我们分别以 Redis 缓存服务和 MySQL 数据库为例,来介绍后端系统水平扩展的技术和核心技术点。 1. Redis 水平扩展 Redis 去年发布了 3.0 版本,官方支持了 Redis cluster 即集群模式。至此结束了 Redis 没有官方集群的时代,在官方集群方案以前应用最广泛的就属 Twitter 发布的 Twemproxy (ht
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.3.2 数据库调优 随着运营推广的开始,业务进入快速增长期,数据库作为后端系统唯一或者主要持久 化组件,无论是存储的数据量还是事务请求次数都呈现大幅增长,数据库的事务处理能力 逐渐成为整个系统性能瓶颈。增加物理资源虽然可以起到一定程度的缓解作用,但是毕竟 是一种治标不治本的方法。分布式数据库虽然听起来高端,但是其系统改造成本及学习运维成本又让一般的中小型团队望而却步。SQL 优化,根据用户访问的 SQL 语句,对数据库 的表结构,尤其是索引进行优化,能够有效加速 SQL 的执行效率,对于开发者来说是最简 单有效的解决方案。接下来
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验 4.2.5 系统通信 1. 系统通信的应用场景  按照应用场景,系统通信可以分为系统间和系统内部两种,从技术角度上看,两种方 式没有实质的区别。但在实际场景中,会涉及部署环境、系统兼容等问题,需要根据具体 的场景进行分析。 系统内通信:随着系统规模的增大,单体架构会越来越复杂,因此必须对原有系 统进行拆分和部署。从另外一个角度看,单点的计算能力,可靠性总是有限的, 现在的技术方案也倾向于使用集群部署来解决问题。一个系统的多个独立模块之 间要协同工作,需要模块之间的通信能力。 系统间通信:一个系统不可能完全孤立,
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.2.6 消息中间件 消息中间件是分布式系统中重要的组件,如图 4-12 所示,它能够解决应用耦合、异步 投递消息、流量削峰等问题,实现高性能、高可用、可伸缩和最终一致性架构,是大型分 布式系统不可缺少的中间件。  [图片]图 4-12 消息中间件 1. 消息模型  队列(Queue)  队列模型下,一条消息只会被一个消费者处理,如图 4-13 所示。在多个消费者的情况下,生产者投递的消息一般会平均投递到不同的消费者。  [图片]图 4-13 队列 如果使用场景单一,如日
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.3 系统优化 系统扩展,着眼点是系统节点的横向扩展,重点是增加系统的整体吞吐量,对于提升 用户单次访问没有什么帮助。相反,加入更多横向扩展的中间设施和各种逻辑,往往会减 慢而不是加快用户的访问速度。 无论什么产品,最终要为用户服务,因此除了服务端的承载能力之外,用户的访问性能、产品本身单点稳定也是要考虑的内容。从某种角度上来说,用户访问性能比服务端整 体性能更为重要,因为这会切实影响到用户的实际体验。如果说系统扩展是“外功绝学”, 重点在于系统的整体表现,系统优化就是“内功心法”,重点提高系统内部的处理能力和稳 定性,为
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.6 DevOps DevOps 理念是提倡开发、测试、IT 运维之间的高度协同,从而在完成高频率部署的 同时,提高生产环境的可靠性、稳定性、弹性和安全性。为什么是开发和 IT 运维?因为产 品价值流在业务(定义需求)和客户(交付价值)之间。 DevOps 本身并不能完全被工具或软件来简单地定义或量化。但工具或软件是实现 DevOps 的一个重要组成部分,现在流行的 Docker 就是实现 DevOps 最合适的工具之 一。Docker 的起源和产品功能,与 DevOps 的理念非常匹配。Docker 完全有能力来加 速、保障软件
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.6.4 大应用编排 一套大的应用方案包含多个模块和服务,通常做法是编排一套脚本,在脚本中定义好 各个模块的配置和依赖,就可以用脚本在多个环境中部署。Docker 容器服务使应用编排更 便捷,Docker Compose 的语法已在大多数云平台得到广泛的应用。 本节将介绍如何在原生的 Kubernetes 平台上编排一套 ELK(Elasticsearch、Logstash 和 Kibana)应用服务。语法为 Yaml 格式。 原生 Kubernetes 平台搭建  搭建一个 Kubernetes 集群可以用开源软件 mi
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.5 数据库诊断 数据库作为一个大型的并发存储系统,其内部设计极其复杂,开发者在使用数据库时, 面临着可用性、可靠性、性能、安全、扩展性等多重挑战,这使得数据库的使用具有较高 的技术门槛。一般大型团队都会雇佣专职的 DBA 来维护数据库的日常运行,指导开发者建 立正确的使用姿势,但是对于中小型团队而言,受限于人力成本,这种模式难以实现。随 着 DevOps 理念的流行,开发者开始更多地参与和承担数据库的运维工作,其中就包括对 数据库的定期健康检查。 对数据库定期进行健康检查是数据库日常维护的重要环节,通过检查数据库的各项
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.4.2 性能问题诊断 在性能诊断之前,我们要先清楚如何判定,或者说如何确定应用有性能问题,否则无 法定位性能问题。总的来说,性能指标主要有以下两点。 吞吐量:每秒可以处理的请求数据或者任务数据。 响应时间:处理一个请求/任务的时间或者延迟。 整个系统的性能基本由这两个指标来反映,系统对性能指标可能有不同的偏好,在有 些场景下,系统可能偏好更高的吞吐量,这样可以同时服务更多的用户;但在另外一些场 景下,系统可能偏好低延迟或者响应时间短,这样可以快速返回单个请求,保证用户良好 的使用体验。 这两个指标相互影响,缺
  • 勿忘初心2018-11-15
    欢迎访问网易云社区,了解更多网易技术产品运营经验。 4.4.3 基于日志的故障诊断 日志是故障诊断的重要手段,可以记录程序运行时的动态信息,帮助维护人员分析重现 错误,进而更正系统错误,提高系统运行的可靠性。但通过日志进行故障诊断并非易事。随 着时间的积累,日志越来越庞大,用户常常无法快速地定位问题日志。而且单台机器的空间 有限,每隔一段时间就会删除日志文件,这对于问题的追溯也造成了困难。 尤其对于分布式系统来说,日志分散在系统各个节点上,更增加了日志的查看和错误 发现难度,用户登录几十或上百台机器查看日志是个极大的负担。另外对于多个服务组成 的系统(比如微服务系统)来说,