背景当前glance镜像通过虚拟机安装好系统后，一般静态的放在glance的镜像服务器上。但是如果因为应用或者镜像制作有点小的偏差，比如修改/etc下软件的配置等，一般的方法是从新把镜像拷贝到openstack计算节点上，用该镜像文件创建虚拟机，修改完成后，再把镜像拷贝到镜像服务器上，如果镜像很大，整过过程会有很大的人力和资源开销。现在提供一种非常简便的方法，因为一般在kvm环境中，glance的镜像格式一般为raw或者qcow2，qemu工具链中提供了qemu-nbd，qemu-nbd可以将镜像文件与内核nbd设备关联，这样把nbd设备mount，就可以看到镜像内部的全部信息，将需要修改的文件进行修改，完成后进行umount，然后用qemu-nbd将nbd设备与镜像文件解关联，省去了镜像拷贝，虚拟机启动等一系列操作。方法环境说明：系统：CentOS-7.2，内核版本：3.10.0-327.el7.x86_641、内核nbd设备支持当前在CentOS-7.2中，默认是没有nbd的内核模块，可以通过 modinfo nbd 查看一下，如果没有，可参考 http://purplepalmdash.github.io/blog/2015/08/13/build-nbd-kernel-module-on-centos7/ 进行手动编译nbd内核模块，这里就不在叙述.2、qemu-nbd工具 ...继续阅读 (51)

前言之所以写这篇文章，是因为通常使用的批量创建虚拟机的方式，可以创建成功，但是无法获取到本次批量创建的虚拟机列表。现找到了一种方法可以获取，在此分享一下。常用的批量创建虚拟机方法1、在 horizon 上创建使用horizon页面创建时，可以直接填写要创建的数量。创建后，在虚拟机列表出能看见正在创建的虚拟机(状态)。2、使用 nova boot 命令行用 nova boot 命令行创建时，带上 --max-count 和 --min-count 参数，指定创建的最大数量和最小数量，可以实现批量创建。3、使用 nova apinova api批量创建虚拟机的 url 为 /servers，参数中指定 max_count 和 min_count ，即批量创建的最大数量和最小数量，可以实现批量创建。三种方法只是使用的 client 不同，最终都会调用nova api。方法1和2最终也会使用方法3（即nova api）的形式创建。先补充说明一下方法2和方法3中的参数 --max-count（max_count）和 --min-count（min_count）。两个参数的解释是允许创建的最大数量和最小数量。起初以为是在 nova scheduler 调度时，尽量按照 max_count 创建，如果资源不够再取 min_count，如果还不够则返回失败。跟踪了代码以后，才发现这两个参数并不影响 ...继续阅读 (35)

问题现象服务器发生内核panic，根据panic堆栈来看，是ext4文件系统报错，基本意思是访问特定扇区位置出错了，从而导致了内核panic，日志如下：panic重启后，发现系统无法启动，从bmc上面来看，系统完成BIOS关于硬件初始化后，grub没有出现，bmc上面呈现黑屏状态，没有任何信息。解决过程问题定位一般linux发布版系统都会提供修复模式的系统，需要在grub中选择启动的系统，但是这次的问题是grub都没有看到，基本上就是在BIOS完成后就没有了下文了，基本可以确定了问题大概原因：磁盘硬件损坏；磁盘分区损坏；grub损坏。这里仅仅是猜测，需要先确定硬件是否正常。需要有一个可用的系统把服务器驱动起来，第一个想到的是livecd。通过bmc把livecd iso挂载到服务器上，成功启动了服务器。启动后，因为当前主机上存储较多的磁盘，需要通过fdisk找到先前的系统盘（因为是livecd系统，所以sda不一定是系统盘）。看到的磁盘有Linux swap / Solaris之类的分区，基本上就是系统盘了。接下来就要判断磁盘是否正常，直接简单的方法就是mount，先mount /dev/sda3，因为该分区较大，可以大胆猜测是根分区，# mkdir /data # mount /dev/sda3 /data发现可以成功mount，那么根分区没有问题，再去mount /dev/sd ...继续阅读 (29)

前言修改物理机上的登录账号的权限，修改了/etc/sudoers以后，发现nova-compute工作异常了。日志中报错:2016-05-17 10:49:00.202 18893 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/nova/utils.py", line 272, in execute2016-05-17 10:49:00.202 18893 ERROR oslo_service.periodic_task return processutils.execute(*cmd, **kwargs)2016-05-17 10:49:00.202 18893 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py", line 275, in execute2016-05-17 10:49:00.202 18893 ERROR oslo_service.periodic_task cmd=sanitized_cmd)2016-05-17 10:49:00.202 18893 ERROR oslo_service.periodic ...继续阅读 (82)

前段时间，维护的一个golang服务出现了一次问题：请求无响应且无日志输出。重启进程后，服务恢复了正常，但却没有足够信息来跟进分析此次问题了。之前运维过java服务，java的分析工具还是比较丰富的，针对thread有jstack或者可以发送SIGQUIT信号，针对heap有jmap等，以及其它基于JMX的分析工具。以类似的思维来分析golang服务的问题，先获取goroutine的stack trace信息。golang提供了runtime这个包，其Stack函数可以输出所有goroutine的stack trace信息；另外，golang进程也可以接受SIGQUIT信号，默认会输出目前的goroutine的stack trace信息，但是主进程会以返回码2退出。所以，如果不侵入代码且不影响进程正常运行，基本无法获得goroutine的stack trace信息。当然，这也提醒我们如果线上的golang服务出现了问题需要stack trace，至少应先发送个SIGQUIT信号保留现场goroutine的stack trace信息，然后再进行重启等处理。如果利用golang的channel，侵入应用代码，则可以实现类似java的thread dump的效果，这样在收到SIGQUIT信号后会输出goroutine的stack trace，同时golang进程会正常运行。代码如下：pa ...继续阅读 (36)

openstack多集群管理1 背景介绍由于有些物理集群处于不同的地点，或者某一些物理集群规模太大，就需要创建多个openstack集群对其进行管理。而每个openstack集群是单独管理的，这就导致管理入口太多，不方便统一管理。那么就需要一种统一管理的机制。2 方案对比2.1 nova AZ针对多个集群处于不同地点的情况，这时每个集群可以作为一个（或者多个）AZ，但是由于AZ之间还是会共享很多服务，比如neutron，glance，mariadb，rabbitMQ等，需要跨机房访问这些服务，时延比较大，也会消耗较多的机房间带宽，会影响用户体验。 当单个物理集群太大时，即使划分了多个AZ，从逻辑上分割开了，但是rabbitMQ，glance，neutron，mariadb等服务的压力还是会比较大，同样会影响用户体验，划分多个AZ是无法解决这类问题的，AZ只是一个逻辑范围的划分。2.2 multi-region一个region可以对应一个物理集群，region与region可以是不同地点的物理集群，也可以是单个大规模物理机集群分割后的多个物理集群。region之间只共享dashboard service（horizon）和identity service（keystone），也就是说使用统一的管理界面和认证，其他服务（例如，nova，neutron，glance，cinder，ma ...继续阅读 (42)

1.引言Docker daemon是docker架构中运行在后台的守护进程，docker daemon架构大致分为四部分:docker server,docker engine,docker job和docker drivers。四者之间的关系大致可以分为，docker daemon通过docker server模块接收 docker client的请求，并在docker engine根据不同的请求创建出不同的docker job并执行这些job。docker engine通过docker driver完成不同的job的执行。docker server又可以细分为http server，router,以及route handlers。docker server根据不同的请求，完成不同的route转发至handler，并通过docker engine api创建不同的docker job。本章主要介绍docker daemon的创建，初始化流程和docker daemon的销毁流程。注：代码基于docker-1.9.0-dev2.Docker daemon的启动流程docker daemon的启动入口还是在docker项目的main()函数中,通过判断docker启动参数中是否包含daemon cammnd来启动docker client还是docker daemon。因此,d ...继续阅读 (40)

概述KVM虚拟机在遇到OOM后然后就hang住了，长时间无反应，不得不重启进行恢复。这篇文档总结了hang住的原因以及背后的机制，供以后遇到类似问题做参考。主要是涉及到OOM的机制，进程组，以及nginx的进程模型。问题现象系统在内存不足的情况下，就无法通过ssh登陆进去这是可以理解的；无法理解的是，内存不足时，杀掉进程就可以释放出来一部分可用内存，从而让系统能够继续运行下去，可是这个时候为什么会一直hang在这里呢？ 这是内核的bug还是什么原因？系统日志由于系统长时间hang在那里，而且事先也没有打开hungtask，softlockup之类的检测，所以不得不去重启恢复，现场也无法保留了。这也给了我们一个教训：现有的Linux调试手段，如果不影响性能，我们还是要部署到服务器上。在系统重启后，去查看系统日志/var/log/messages, 发现了在重启前的一段时间内核一直在打印如下一段信息：Jan 18 09:50:59 kernel: [ 8202] 0 8202 27050 55 3 0 0 bashJan 18 09:50:59 kernel: [ 8234] 0 8234 27600 455 3 0 0 rsyncJan 18 09: ...继续阅读 (17)

摘要本文一是为了讨论在Linux系统出现问题时我们能够借助哪些工具去协助分析，二是讨论出现问题时大致的可能点以及思路，三是希望能给应用层开发团队介绍一些Linux内核机制从而选择更合适的使用策略。前言搜索团队的服务器前段时间频繁出现CPU load很高(比如load average达到80多)的情况，正所谓术业有专攻，搜索的兄弟们对Linux底层技术理解的不是很深入，所以这个问题困扰了他们一段时间。相信我们在遇到问题时都有类似的经历，如果这个问题涉及到我们不熟悉的领域，我们往往会手足无措。由于虚拟化团队具备一些Linux底层背景知识，所以在知晓了这个搜索团队遇到的困难后，就开始协助他们定位出问题根因并帮助他们解决了问题。我希望能借助这个机会给大家介绍一下在Linux系统出现问题时我们能够借助哪些工具去协助分析；以及介绍一下Linux在内存管理方面的一些机制以及我们的使用策略。Linux系统出现问题，我们该如何去分析工欲善其事，必先利其器。要解决问题，首先得去定位问题的原因。在Linux系统里面有很多的问题定位工具，可以协助我们来分析问题。于是我们就针对目前搜索服务器的现象，思考可以借助哪些工具来找到问题原因。Linux系统响应慢，从内核的角度看，大致可能有以下几种情况：线程在内核态执行的时间过长，这个时间超出了它被调度算法给分配的执行时间，它在内核态长时间的占用CPU，而且也不返回 ...继续阅读 (16)

随着Docker的出现，PaaS、CaaS（Container As A Service）、甚至DCOS（DataCenter OS）呈现了爆发式的发展。而在PaaS中，因为实例一般默认为动态IP，对于7层调用（比如http请求），需要7层动态路由获取应用域名（或虚IP）和后端实例的映射关系，以提供7层服务；而对于4层调用（比如rpc调用），可以通过动态LVS或名字服务（或基于zookeeper/etcd等实现的服务注册和发现工具）进行调用。简单举例，开发者在PaaS里创建了一个APP，包含若干个实例，然后为APP绑定某个域名。用户对APP发出请求，需要经过后端实例的处理才能正确的返回。那么作为7层动态路由，核心就是获取域名（或虚IP）与后端实例的对应关系并作为反向代理完成请求转发。这里简单讨论下7层动态路由的若干实现。因为nginx是一个高性能的反向代理服务器，以是否基于nginx实现7层动态路由，可以将这些实现大概分为两大类。第一类，不依赖nginx，项目自身实现了反向代理的功能。CloudFoundry可以说是第一代的开源PaaS项目，其模块gorouter即为一个动态路由实现（同时支持4层和7层）。以CloudFoundry (release v164)为例，使用nats作为消息总线，对各模块调用和消息传递进行解耦。可以看下gorouter (tag 45ca951297) ...继续阅读 (168)

一、概述在数据中心的虚拟化环境中，出现过部分虚拟机和同网段的、在不同物理机上的其它虚拟机之间ping不通的情况。例如物理机A上有ip为10.11.8.220的虚拟机vm1，物理机B上有ip为10.11.8.223的虚拟机vm2，从vm1上ping vm2的ip时断时续，反过来vm2 ping vm1甚至都不会通。但是vm1和vm2各自ping网关ip 10.11.8.1都是通的，而且从跨网段的虚拟机（例如物理机C上有ip为10.15.3.41的虚拟机vm3）上ping vm1和vm2也都是通的。另外，在出现ping不通的情况时，如果把宿主机的ip_forward功能打开，虚拟机就又能马上ping通。二、问题背景与现象发生问题的虚拟化环境组网如下所示：具体物理环境配置：bond采用的是bond6负载均衡模式host1的ip_forward转发开关关闭，host2的打开vm1的ip是10.11.8.220，mac地址是FA:16:3E:5A:D5:FEvm2的ip是10.11.8.223，mac地址是FA:16:3E:1E:A0:1Ahost1的ip是10.11.8.21，两块网卡的mac地址分别是F0:1F:AF:DF:D6:40、F0:1F:AF:DF:D6:41host2的ip是10.11.8.22，两块网卡的mac地址分别是F0:1F:AF:DF:EF:2D、F0:1F:AF: ...继续阅读 (37)

1. 背景容器虚拟化带来轻量高效，快速部署的同时，也因其隔离性不够彻底，给用户带来一定程度的使用不便。Docker容器由于Linux内核namespace本身还不够完善的现状(例如，没有cgroup namespace,user namespace也是在kernel高版本才开始支持, /dev设备不隔离等)，因此docker容器在隔离性方面也存在一些缺陷。例如，在容器内部proc文件系统中可以看到Host宿主机上的proc信息(如：meminfo, cpuinfo，stat， uptime等)。本文基于开源项目LXCFS，尝试通过用户态文件系统实现docker容器内的虚拟proc文件系统，增强docker容器的隔离性，减少给用户带来的不便。2. LXCFS简介及原理2.1 LXCFS介绍LXCFS是一个开源的FUSE用户态文件系统，起初是为了更好的在Ubuntu上使用LXC容器而设计开发。LXCFS基于C语言开发，代码托管在github上,目前较多使用在LXC容器中。主要由Ubuntu的工程师提供维护和开发。LXCFS主要提供两个基本功能点：a cgroupfs compatible view for unprivileged containersa set of cgroup-aware files:/proc/meminfo/proc/cpuinfo/proc/stat/pro ...继续阅读 (94)

内容简介在公司内部的docker实践中，有时候会出现一些稳定性问题，例如docker容器无法启动等，尤其是版本较早的docker。另外，在容器镜像内部有时候也会因为配置不当而导致容器启动不起来，这个时候，如果了解了docker所采用的存储技术的原理，那么就可以实现不启动容器，就把容器的数据卷挂载到宿主机的指定目录上，然后再到其中做修改或备份数据工作，使容器恢复正常并恢复重要数据技术原理1、docker镜像的典型结构如下图所示。传统的Linux加载bootfs时会先将rootfs设为read-only，然后在系统自检之后将rootfs从read-only改为read-write，然后我们就可以在rootfs上进行写和读的操作了。但docker的镜像却不是这样，它在bootfs自检完毕之后并不会把rootfs的read-only改为read-write。而是利用union mount（UnionFS的一种挂载机制）将一个或多个read-only的rootfs加载到之前的read-only的rootfs层之上。在加载了这么多层的rootfs之后，仍然让它看起来只像是一个文件系统，在docker的体系里把union mount的这些read-only的rootfs叫做Docker的镜像。但是，此时的每一层rootfs都是read-only的，我们此时还不能对其进行操作。当我们创建一个容器 ...继续阅读 (51)

内容简介本文根据docker官方给出的docker代码编译环境搭建指南做更深入的分析。官方给出的指导比较简单，但是由于国内的网络问题经常会编译失败，了解了编译步骤后，也可以结合自身遇到的网络问题进行“规避”。https://docs.docker.com/v1.5/contributing/devenvironment/docker的编译环境实际上是创建一个docker容器，在容器中对代码进行编译。如果想快速的查看编译环境搭建指导，而不关注环境搭建的机制和细节，可以直接跳到最后一章“总结”。前提机器上已经安装了docker，因为编译环境是个docker容器，所以要事先有docker（daemon），后面会创建个编译环境容器，在容器里面编译代码。本文中使用物理机，物理机上运行着docker （daemon）。机器（物理机）上安装了git 。 后续使用git下载docker源码机器（物理机）上安装了make。下载ubuntu 14.04的docker镜像下载docker源码git clone https://git@github.com/docker/docker会把代码下载到当前目录下，后面会把代码拷贝到容器中。编译前分析官方给的编译方法是make build 和 make binary等。下面先分析Makefile，看懂Makefile后，编译环境的准备流程就比较清楚了。Make ...继续阅读 (26)

10x Engineer: a developer who incurs technical debt so fast he appears more productive than the 10 developers tasked w/ cleaning his mess up我们都知道，全局变量应该尽量少用或不用，因为它会带来两个明显的问题：耦合和不确定性。有了它，单元测试就不好进行，即使通过了测试，也不能确保这个全局变量变了之后是否能通过测试。 我们经常使用的单例就有全局变量的意味：外部可以直接拿来用，并且可以在任何地方被修改。为了加快开发速度，往往会以功能实现优先，其中的一个「方法」就是提供可变对象，比如像 OC 里的NSMutableDictionary。前两天正好遇到一个与此有关的 case，可以拿出来说一下。我们的网络层发送请求时，默认会带上一些系统参数，比如 iOS 系统版本，app 版本等。同时如果用户已经登录了，也会带上一些用户信息，比如token。为了方便复用，我们每次请求都会把已有的参数放在一个自定义的网络请求类，假设这个类的名字叫APIClient。同时又允许外部动态添加一些请求参数，比如用户信息，是否启用调试等。出于方便考虑，我们给APIClient类加了一个NSMutableDictionary属性builtinParameters，这样外部只要拿到A ...继续阅读 (29)

这阵子比较忙，组里的赤(xing)木(xing)大(dui)神(zhang)一直催我写第二篇。今天抽出空来，把这篇补上。上一篇已经交代了如何把一个插件apk动态加载到内存中，并做到可用。这篇介绍的是，我们如何在“合适”的时间加载某个插件。试想一个理想化的场景，一个app中，所有的模块都是一个个的插件，我们不可能在应用初始化的时候把所有的插件全部加载，dex optimize时长都能把人弄哭。那么就得找一个时间点，使我们可以知道，某个插件第一次被用到是什么时候，只要在这个时间加载这个插件就好。分析一下插件主要有哪些东西构成：首先是逻辑代码，这些函数有些是自己插件内部用的，有些是外部其他插件也要用的。页面，各种Activity。Ok，我们一个个得解决上面的问题对外函数在这种情况下，如果一个插件A需要调用插件B的函数，我们可以去检查插件B是否被加载过，如果还未加载，就加载它。这里不知道大家会不会有个疑问，我们是如何感知到插件A调用了插件B中的函数了呢？首先有个天然性的隔离就是，插件与插件之间在开发的时候，都是独立工程的，它们之间不应该存在直接的函数调用。然后，我们需要一个中间管理框架，用来统一处理插件间的函数(服务)调用，这也是蘑菇街组件管理框架所做的很重要的一件事。所有的插件/组件之间的函数(服务)调用，必须过管理框架中转，最后由框架进行实际的调用。由于管理框架是一个通用框架，并不针对 ...继续阅读 (53)

MVVM 是 MVC 模式的一种演进，它主要解决了 ViewController 过于臃肿带来的不易维护和测试的问题。其中 ViewModel 的主要职责是处理业务逻辑并提供 View 所需的数据，这样 VC 就不用关心业务，自然也就瘦了下来。ViewModel 只关心业务数据不关心 View，所以不会与 View 产生耦合，也就更方便进行单元测试。View 是一个壳，它所呈现的内容都需要由 ViewModel 来提供，而 View 又不与 ViewModel 直接沟通，这时就需要 ViewController 来做中间的协调者。ViewController 持有 View 和 ViewModel，当 VC 初始化时，会让 ViewModel 去取数据，简单来说就是调用 VM 的某个获取数据的方法。使用 MVVM 最舒服的姿势是搭配 ReactiveCocoa。不过它的问题在于学习成本和维护成本比较高，在小团队中或许还可以尝试，当开发人员数量较多时就很难推起来了。这也是我们今天要讲的主题：如何不借助 ReactiveCocoa 来实现 MVVM。先从数据的获取开始说起吧。在 ReactiveCocoa 里有一个类叫「RACCommand」，它的主要作用是执行某个会改变数据的操作，然后提供获取数据的方法，跟我们想要达到的目的很像，所以可以借鉴这个思路，写一个简单的 Command。t ...继续阅读 (62)

插件化的基石 -- apk动态加载随着我街业务的蓬勃发展，产品和运营随时上新功能新活动的需求越来越强烈，经常可以听到“有个功能我想周x上，行不行”。行么？当然是不行啦，上新功能得发新版本啊，到时候费时费力打乱开发节奏不说，覆盖率也是个问题。苏格拉底曾经说过：“现在移动端的主要矛盾是产品日益增长的功能需求与平台落后的发布流程之间的矛盾”。当然，作为一个靠谱的程序猿，我们就是为了满足产品的需求而存在的(正义脸)。于是在一个阳光明媚的早晨，吃完公司的免费早餐后，我和小强、叶开，决定做一个完善的Android动态加载框架。Android动态加载技术在蘑菇街的第一次实践，还是在14年的时候，使用的就是之前网上广(tu)为(du)流(si)传(fang)的方式，这种方式有一个重大缺陷，就是插件内部对资源的访问只能通过自己定义的方式，包括对layout文件的inflate等，使用getResouces的方式，分分钟crash给你看，而且内部实现有些复杂，容易出现莫名其妙的ResourcesNotFound错误。在一段时间的使用之后，始终无法大面积推广，原因就是对开发人员来说，写一个“正常”的模块和写一个动态加载模块，写法是不一样的。这件事一直如哏在喉，如果这个框架无法做到对开发业务的同学们透明，那么就很难推广开去。如何做到对业务开发者透明呢，最重要的是对于各类系统api的使用，尤其是Androi ...继续阅读 (43)

统计打点是 App 开发里很重要的一个环节，App 的运行状态、改版后的效果、用户的各种行为等都需要打点，市面上也有不少可供选择的第三方库。 假设产品有这么个需求：当用户在详情页点击购买按钮时，记录一下事件。我们实现起来大概会是这样// DetailViewController.m - (void)onBuyButtonTapped:(UIButton *)button { // do some stuff, maybe send a request to server [XXXAnalytics event:kSomeEventYouDefined]; }这个需求就这样轻松搞定了，但细细想想还是有不少问题的：页面上会有其他的 Button，可能每个 Button 都要放上这么一段代码。这些统计其实跟具体的业务无关，没必要跟业务代码混杂在一起，不优雅。当改版或者重构时，有可能忘了把相应的打点代码迁移过去。所以需要一种更好的方式来做这件事，这就是使用 AOP(Aspect-Oriented-Programming)，翻译过来就是「面向切面编程」通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。简单来说，就是可以动态的在函数调用的前后插一段代码。iOS 可以使用 Pete Steinberger 开发的Aspects这个库，大致 ...继续阅读 (68)

项目内容简介hulk是一个胶水型的系统，联结Pigeon(数据事件系统)，Tesla（服务化框架）， Sentry（统计组件）以及业务方自身开发组件， 完成DB事件驱动型的任务。它利用脚本引擎，加载业务逻辑脚本，快速解决问题，支持热部署，免去业务方的重复劳动，大大提升开发效率。业务需求分析1. 基于DB数据事件的相应处理需求增多(例如 需要监听商品数据变更做相应调整， 静态化失效中心) 2. 主业务流程的减负和异步化需求 (例如 商品发布流程中提交反作弊反垃圾审核) 3. 数据统计的需求，现在数据团队可提供一定范围内的sum，但是没法反应实时的数据状态(例如，每天各个时段新增的商品数，更新商品数) 4. 目前搭建java工程使用服务化 API比较麻烦，主业务流程之外的附属工作多，同时各个工程之间重复度很高。 5. 业务方有监控的需求，工程发生异常需要报警通知系统设计原则1. glue like, 做得轻薄，尽量利用站内现有的技术组件，只做系统之间的粘连 2. 部署&调试方便, 使业务方专注自身业务开发，支持热部署 3. 对业务方组件友好，方便业务方添加自身组件 4. 高可用性项目优点1. 快速提升业务开发效率，原有完成一个类似系统需要自建java工程，需要写一堆自身业务不相关代码，现在业务方可专注自身业务代码 2. 有监控，有报警，可展示 3. 可扩展性高，组件和容器重用方便整体架 ...继续阅读 (48)

JDK1.6以后包含了java.util.ServiceLoader类，但对于这个工具类的作用可能很多Java工程师未必了解。本文就希望通过一个如何用ServiceLoader实现模块加载机制的案例，来试图讲解ServiceLoader的应用。ServiceLoader介绍我们通常所指的服务就是指一些接口和类的集合，而一个服务提供者就是指一个服务的具体实现，Java平台一般都是通过特定扩展机制来加载服务实现的。ServiceLoader就是这样一种扩展机制的实现。ServiceLoader的机制要求服务提供方的jar必须包含一个META-INF/services目录，目录里面需要存在以服务类型名称（包含包名和类名）命名的文本文件,比如META-INF/services/com.example.Service1文件内容要求很简单，每一行放一个这个接口的一个实现类的类型名称（包含包名和类名），比如：com.example.Service1Impl1 com.example.Service1Impl2准备好这些后，我们就可以调用ServiceLoader获取这些服务实例，代码如下：ServiceLoaderservices = ServiceLoader.get(Service1.class);这时候ServiceLoader会帮我们去扫描classpath下所有的META-INF/se ...继续阅读 (54)

通用灰度开关项目背景交易组内新代码发到线上通常要经过五大步骤：第一，内部单元测试第二，发布前代码审核第三，线下测试机测试第四，线上灰度测试第五，灰度测试完毕后新代码完整发布上线前四步中任何一步出现问题，都要找出问题修复代码，再重新进入发布流程。其中第四步线上灰度测试，涉及线上业务过程也复杂一些。线上灰度测试分成两种情况：第一，新代码在一定灰度比率内正常，继续提高灰度比率测试，并重发代码第二，新代码在一定灰度比率内异常，代码回滚，修复新代码bug，再次进入重新发布流程这两种情况都有很大不足：无论代码是否正常，提高灰度比率都需要重新发布。这对代码正常的情况是不合理的；新代码出现问题，要进行回滚操作，这段时间业务处于不可用状态，影响业务的正常运行。随着新业务的不断上线，出现问题也在所难免。如何减少因以上问题造成对业务的影响，提高发布效率，减少异常处理时间，让研发同学把更多精力放在开发上，已成为亟待解决的问题。项目介绍通用灰度开关系统为业务接入方提供灵活、稳定、高可用的灰度开关服务。支持从业务到方法级别灰度开关的灵活控制；系统接入方便，接口稳定；提供99.999%的高可用性，全年故障时间在5分钟以内。系统可减少不必要的发布次数，缩短异常情况对业务的影响时间。当新业务正常时，提高灰度比率时代码无需重发；异常时，无需回滚代码，即可让业务逻辑在5s后切换至旧逻辑，对业务的影响时间缩短至5s。系统 ...继续阅读 (26)

通用灰度开关项目背景交易组内新代码发到线上通常要经过五大步骤：第一，内部单元测试第二，发布前代码审核第三，线下测试机测试第四，线上灰度测试第五，灰度测试完毕后新代码完整发布上线前四步中任何一步出现问题，都要找出问题修复代码，再重新进入发布流程。其中第四步线上灰度测试，涉及线上业务过程也复杂一些。线上灰度测试分成两种情况：第一，新代码在一定灰度比率内正常，继续提高灰度比率测试，并重发代码第二，新代码在一定灰度比率内异常，代码回滚，修复新代码bug，再次进入重新发布流程这两种情况都有很大不足：无论代码是否正常，提高灰度比率都需要重新发布。这对代码正常的情况是不合理的；新代码出现问题，要进行回滚操作，这段时间业务处于不可用状态，影响业务的正常运行。随着新业务的不断上线，出现问题也在所难免。如何减少因以上问题造成对业务的影响，提高发布效率，减少异常处理时间，让研发同学把更多精力放在开发上，已成为亟待解决的问题。项目介绍通用灰度开关系统为业务接入方提供灵活、稳定、高可用的灰度开关服务。支持从业务到方法级别灰度开关的灵活控制；系统接入方便，接口稳定；提供99.999%的高可用性，全年故障时间在5分钟以内。系统可减少不必要的发布次数，缩短异常情况对业务的影响时间。当新业务正常时，提高灰度比率时代码无需重发；异常时，无需回滚代码，即可让业务逻辑在5s后切换至旧逻辑，对业务的影响时间缩短至5s。系统 ...继续阅读 (31)

前言大家都知道利用缓存技术是提升网站性能和稳定性的利器，比如利用redis集群来缓冲mysql的压力，利用opcache缓存编译后的bytecode提升php的性能等等，同样对于网站的整体架构而言，如果一些数据更新频率不高的页面，没有必要每次都从数据库里读取数据，一来调用数据库，响应速度慢；二来增加数据库服务器的负荷，在大促时尤其明显；三，依赖过多的底层组件，如solr，mysql，redis，当出现单点故障的时候，会导致页面的可用性急剧下降。因此在上半年，我们对蘑菇街App端商品详情页做了页面静态化的改造，经过差不多半年的线上运行和大促的考验，效果比较明显，mobile_goods_pool集群的压力明显降低，商品详情页的平均RT由原来的200ms下降到现在的100ms不到，整体稳定性达到了99.99%。内容大纲动态页面的动静分离怎么做页面是怎么缓存的，在哪一层做的缓存数据一致性怎么保证，缓存失效是如何处理的动静如何分离动静分离我们将商品详情页的数据做了动静拆分，静态数据包含图片，详情，喜欢列表，评价列表等等，动态数据则包含是否喜欢，评价列表里的是否关注评论者等个性化数据，一次请求拆分成了两次请求，detail和detail_dyn，其中detail请求从缓存中取数据动态数据如何获取在最初的设计方案里面，我们考虑用异步请求的方式，App端获取数据时请求两次，第一次请求静态数据后， ...继续阅读 (33)

前言大家都知道利用缓存技术是提升网站性能和稳定性的利器，比如利用redis集群来缓冲mysql的压力，利用opcache缓存编译后的bytecode提升php的性能等等，同样对于网站的整体架构而言，如果一些数据更新频率不高的页面，没有必要每次都从数据库里读取数据，一来调用数据库，响应速度慢；二来增加数据库服务器的负荷，在大促时尤其明显；三，依赖过多的底层组件，如solr，mysql，redis，当出现单点故障的时候，会导致页面的可用性急剧下降。因此在上半年，我们对蘑菇街App端商品详情页做了页面静态化的改造，经过差不多半年的线上运行和大促的考验，效果比较明显，mobile_goods_pool集群的压力明显降低，商品详情页的平均RT由原来的200ms下降到现在的100ms不到，整体稳定性达到了99.99%。内容大纲动态页面的动静分离怎么做页面是怎么缓存的，在哪一层做的缓存数据一致性怎么保证，缓存失效是如何处理的动静如何分离动静分离我们将商品详情页的数据做了动静拆分，静态数据包含图片，详情，喜欢列表，评价列表等等，动态数据则包含是否喜欢，评价列表里的是否关注评论者等个性化数据，一次请求拆分成了两次请求，detail和detail_dyn，其中detail请求从缓存中取数据动态数据如何获取在最初的设计方案里面，我们考虑用异步请求的方式，App端获取数据时请求两次，第一次请求静态数据后， ...继续阅读 (54)

一、协程是什么?协程(Coroutine)，源自 Simula 和 Modula-2 语言,是一种程序组件，可以理解为是一种可多次返回的函数：int coroutine(){ dosometing_1(); yield(1);//第一次返回 dosometing_2(); yield(2);//第二次返回 dosometing_3(); return 3;//最终返回 }二、协程有什么用？基于其多次返回特性，协程可用作迭代器、事件分发、SAX解析等。但应用最多的，最能体现协程效果的，还是被称为“用户态线程”的合作式多任务。合作式多任务的主要作用，是可以把令人费解的异步程序，用因果自然的同步方法写出来。例如：费解的异步int onRecv(int value){ dosometing_2(value); } void task(){ dosometing_1(); asyncRecv(onRecv);//异步调用onRecv，task返回后释放线程控制权，回掉里重新获取控制权 }清晰的协程void task(){ dosometing_1(); int value=recvViaCoroutine();//协程，释放线程控制权，等真正收到在重新获取控制权 dos ...继续阅读 (40)

一、协程是什么?协程(Coroutine)，源自 Simula 和 Modula-2 语言,是一种程序组件，可以理解为是一种可多次返回的函数：int coroutine(){ dosometing_1(); yield(1);//第一次返回 dosometing_2(); yield(2);//第二次返回 dosometing_3(); return 3;//最终返回 }二、协程有什么用？基于其多次返回特性，协程可用作迭代器、事件分发、SAX解析等。但应用最多的，最能体现协程效果的，还是被称为“用户态线程”的合作式多任务。合作式多任务的主要作用，是可以把令人费解的异步程序，用因果自然的同步方法写出来。例如：费解的异步int onRecv(int value){ dosometing_2(value); } void task(){ dosometing_1(); asyncRecv(onRecv);//异步调用onRecv，task返回后释放线程控制权，回掉里重新获取控制权 }清晰的协程void task(){ dosometing_1(); int value=recvViaCoroutine();//协程，释放线程控制权，等真正收到在重新获取控制权 dos ...继续阅读 (27)

一、协程是什么?协程(Coroutine)，源自 Simula 和 Modula-2 语言,是一种程序组件，可以理解为是一种可多次返回的函数：int coroutine(){ dosometing_1(); yield(1);//第一次返回 dosometing_2(); yield(2);//第二次返回 dosometing_3(); return 3;//最终返回 }二、协程有什么用？基于其多次返回特性，协程可用作迭代器、事件分发、SAX解析等。但应用最多的，最能体现协程效果的，还是被称为“用户态线程”的合作式多任务。合作式多任务的主要作用，是可以把令人费解的异步程序，用因果自然的同步方法写出来。例如：费解的异步int onRecv(int value){ dosometing_2(value); } void task(){ dosometing_1(); asyncRecv(onRecv);//异步调用onRecv，task返回后释放线程控制权，回掉里重新获取控制权 }清晰的协程void task(){ dosometing_1(); int value=recvViaCoroutine();//协程，释放线程控制权，等真正收到在重新获取控制权 dos ...继续阅读 (39)

背景1、我们目前使用openstack+docker来搭建自己的私有云2、openstack有两种网络环境搭建模式，一种是功能较简单的nova-network，一种是neutron方案3、neutron方案代表着未来的趋势，提供更多高级的功能(例如路由功能和负载均衡服务等)，更加方便用户去自定义自己的虚拟化网络4、在已有的几个集群中，我们在线下开发测试环境中搭建了neutron方案的openstack集群目的neutron的设计理念是ip分配应当资源池化，因此在默认的dashboard操作界面上，只能为每个虚拟机指定特定的子网，虚拟机启动时会自动分配该子网可用的ip资源。但是，在很多开发测试场景下，我们还是需要为指定启动的虚拟机配备一个固定的ip，比如需要反复创建、删除虚拟机，这个时候就会希望虚拟机的ip不变，方便测试用例的编写，固定的ip地址也有利于CMDB的管理。前置条件所有的操作都基于openstack项目提供的NeutronClient和NovaClient工具，请确保这两个工具已经安装，可以登录openstack的集群管理节点，在命令行界面执行nova和neutron命令，看是否有帮助提示。执行这两个工具，还需要预先获得权限，例如在管理节点上执行这两个命令的话，首先要执行以下命令，执行后就会在环境变量中保存有admin用户的权限信息：# source /root/keys ...继续阅读 (26)

背景1、我们目前使用openstack+docker来搭建自己的私有云2、openstack有两种网络环境搭建模式，一种是功能较简单的nova-network，一种是neutron方案3、neutron方案代表着未来的趋势，提供更多高级的功能(例如路由功能和负载均衡服务等)，更加方便用户去自定义自己的虚拟化网络4、在已有的几个集群中，我们在线下开发测试环境中搭建了neutron方案的openstack集群目的neutron的设计理念是ip分配应当资源池化，因此在默认的dashboard操作界面上，只能为每个虚拟机指定特定的子网，虚拟机启动时会自动分配该子网可用的ip资源。但是，在很多开发测试场景下，我们还是需要为指定启动的虚拟机配备一个固定的ip，比如需要反复创建、删除虚拟机，这个时候就会希望虚拟机的ip不变，方便测试用例的编写，固定的ip地址也有利于CMDB的管理。前置条件所有的操作都基于openstack项目提供的NeutronClient和NovaClient工具，请确保这两个工具已经安装，可以登录openstack的集群管理节点，在命令行界面执行nova和neutron命令，看是否有帮助提示。执行这两个工具，还需要预先获得权限，例如在管理节点上执行这两个命令的话，首先要执行以下命令，执行后就会在环境变量中保存有admin用户的权限信息：# source /root/keys ...继续阅读 (39)