架构演进——架构演进中的敏捷实践（黄舒泉 Intel）

2011.4加入因特尔，负责内部私有云，在内部推行敏捷，有TDD，Scrum，Kanban。英特尔信息技术工程计算部，跨地域的团队，面向全球的用户。关注企业级私有云的开发和运营。是一个实体设备和虚拟设备相结合的平台，开始向移动市场转移。遇到一个问题，每个部门都需要应用自己的应用，比如APP是否能在系统上运行。公司方法：全球的开发团队上传脚本到私有云，系统去调度代码放在需要的设备上去运行测试。等于管理了物理机和虚拟机。敏捷方面目前主要用Scrum。

架构演进中的敏捷实践，三个阶段：游击队-正规军-特种部队

游击队：LAMP架构；“创业”团队；“瀑布式开发”

特点：装备差，人少。项目刚起步，关注企业内部，需求比较简单，访问量不高。我们追求速度、快！我们是企业内的“创业”团队，我们想在2个迭代周期内把产品做出来，给老大看。整个网站采用LAMP结构（Linux+Apache+M+PHP）

为什么选择LAMP？PHP开发门槛低，系统成型快。Mysql免费；

架构服务于需求。产品需要取得先机，快速开发，功能优先，架构其次。

第一次危机：业务快速增长，运营成本不断增加。

“快”带来的种种问题。用户的增加，架构难以满足性能，稳定性的要求。开发团队缺乏运维的经验：DB,PDU,ARUBA。随着业务的发展，面对接踵而来的新功能，团队难以在现在的架构之上开发。

架构发生演进：不断加入的新功能，重新设计一个插件式的架构，使得加入的新功能变得简单。产品能够配置启用不同的功能模块——Lazy loading。

传统的思维已经不适应快递变化的业务。我们在实际项目中，已经开始采用了一些思维。我们经常地找客户去诉苦。

敏捷的陷阱。敏捷意味着不写文档（实际上一些流程图，用户图对用户后期的使用很重要）；错误使用了迭代开发（story分层问题）；忽视计划的重要性（团队需要有勇气和管理者对弈和抵抗）。

正规军：插件式的架构；运营与开发分离；使用Scrum来管理软件开发过程

项目进入扩展阶段，插件式的结构适应多种开发需求；有专门的Scrum团队。插件是一个独立的业务逻辑，他与核心框架无关且低耦合。插件存放在一个指定的文件夹中，步骤：遍历插件；验证插件的合法性；根据指定规则对插件筛选、排序；将得到的插件列表加入到核心框架的Include path中。

第二次危机：团队在不断扩大，越来越复杂的部署、性能要求，很多团队希望加入进来，美国、俄罗斯。英特尔是个跨国企业，很多国外的开发组需要集成我们的系统。

插件模式的不足：让然是一种集中式的架构。不支持分布式复杂的部署，没有对应用数据拆分，API不够开发，易用。我们自己写的消息队列，重新发明轮子，存在许多重复的工作。

于是我们将目光投向了分布式架构：优点：支持灵活的部署方式，系统不容易出现单点故障，也不会出现所有服务都不可用的情况，系统进一步解耦，分离出不同子项目。可以有其他地区的开发人员专门负责，良好的可伸缩性，方便进行水平式扩展。缺点：部署难度，增加了系统设计和开发的难度，对开人员需要有更高的要求，带来一定的性能问题。

REST API。各部分系统的接口。简单易用，容易上手。所有的资源通过统一的接口访问（HTTP GET,POST,PUT,DELETE）符合程序员OO思想。多种资源呈现方式（text,xml,json）。在软件技术演进中的长期兼容性更好；无状态性可以让不同的服务器来处理同一处理的效率。

关于REST API经验：统一每一个API 的HTTP返回代码（方便开发人员debug，不会使用户迷惑）；使用分页、排序、过滤来帮助客户端处理大量数据；API需要有定义规范，将定义好的API更好的让用户使用。有很多开源的组件可以自动展现API。

迁移消息队列的组件，避免重新发明轮子。开发前先调查下是否有现成的开源解决方案可以使用；认真比较各个方案之间的优缺点；先拿一个小模块进行试验，再在系统中的其他的地方进行推广。比如RabbitMQ（消息队列开源组件）。

技术分享过后，回到管理部分。在跨地域的团队中使用敏捷。在全球化、跨地域团队中使用敏捷？我们使用的方法就是（Scrum of Scrum SOS）。建立Scrum的层级关系，在SM（Scum Master）之间建立定期的Sync会议。SOS会议议程：三个问题（15分钟）上次会议前，我们团队做了什么会影响到别的团队；我们需要怎样与他们进行协作；我们团队遇到什么问题，需要其他团队来帮忙解决？会后总结文档发给大家。

关于时区给大家造成的不变，建议：鼓励各个团队之间的横向交流；让别的团队清楚的知道你的痛苦；电话会议的过程中，保证每个人都知道现在是谁在发言。（英文会议尤为重要）；战胜时差带给我们的不便。尽可能地选择工作时间重合的地方，最好能选择视频会议，电话最起码，再不行就IM和邮件了。

改变我们交流的方式。把老外拉到上海，创造条件让所有的团员能够在一起。老板和老板之间能经常互访，带某个架构师到中国来讲情况。一定要将交流的结果作为文档保留下来，方便以后查看。这在跨地域团队之前尤为重要！跨地域团队之间的交流并不像本地团队那样能够时时刻刻进行。Backlog的描述应该尽可能的详细，流程图；界面交互图。让PO将自己的想法写成用例放在库里，大家可以查看。

必要的技术实践：持续集成！一个稳定的持续集成制度是必不可少的，定义了一个规定，搞挂的CI必须修复才能下班回家；架构设计的规范与编码的规范，自行的添加是坚决不允许的；设计评审和代码评审，我们将静态的代码也加到CI里。

我们的持续集成：我们在云计算平台下起了很多虚拟机，在这个平台上运行测试系统，等于是我们在用我们自己的产品开发自己的产品。

特种部队：基于Web服务的架构；不同职能的团队；持续集成

架构：演进中的架构，分布式，基于REST API，拥抱开源。

业务对架构提出了新的要求，从团队的角度来说，团队发现越来越难发现BUG，或者越来越难修改时；团队自身的变化；与外部系统的集成。

问：Opensouce受限制的问题？

答：有专门一个团队去核实这类OpenSource是否能使用。当然我们也考虑我们公司内部的OpenSource。业界某个特别适用了，我们会拿过来考察一下活跃度，发展趋势，我们公司有没有类似的开发人员在使用。我们拿过来后会进行一个广泛的测试，Fixbug。

问：怎么说服公司为新项目增加资源？

答：开始人很少，开始的目的就是让老板满意，用实力说话。产品得到用户的好评了，通过用户量，和其他部门的评价，去和老板商量。我们的项目确实给英特尔解决了问题。老板最重要的是找资源。

问：集中式到分布式转变很大，很痛苦。前面有用户在集中了，你如何平稳过渡？开发分布式需要一段时间，前边的集中式还需要维护，你们是怎么做到的。

答：集中——分布是一个模块一个模块地抓出来，比如消息队列。我们会在每个迭代加一个重构的特性。我们团队规模就几十个人。

问：SM如何协调开发测试？

答：连接就是CI系统，测试团队是跨区域的。开发和测试是分开的Scrum，有问题就去找PO，不是去找开发。