架构驱动改革：随着单量的快速增长，系统故障所造成的损失是巨大的、不可接受的。需要从架构驱动技术体系的改进、甚至推进产品和业务的变革。同时增加业务的容灾能力，进行了多机房的部署。

　　美丽联合集团技术专家七公：

我加入蘑菇街电商团队后带领团队同学仅用一年便完成服务架构的各阶段升级，主要分以下阶段：

第一阶段蘑菇街系统拆分&服务化1.0体系构建，是我们做PHP全面转型Java体系、初步建成电商基础服务中心的战略规划，在面临不停歇的业务需求和巨大的系统改造压力下，我们采用瀑布流工程方法，通过规划、分析、设计实现、测试、服务产品&文档交付的过程，高质量地把第一阶段的服务化建设根基像打桩一样打牢，然后通过进一步的迭代开发不断完善。

第二阶段购买链路核心服务的性能提升&服务架构1.5和第三阶段服务SLA保障推动稳定性提升&服务架构2.0，实际上是业务迅猛发展、流量不断上涨、日常和大促稳定性保障的强烈需求推动我们自身服务架构的升级。我们通过引入Scrum的敏捷开发模式，项目中的每个人都是猪（敏捷开发中，猪为项目负责人，鸡只是普通参与者，寓意来自猪要牺牲才能提供食物而鸡只要下个蛋就行了），每个人都要为服务框架升级和项目进展负责。

　　如何评审架构

　　唯品会资深架构专家张广平：

对于是否做架构评审，我们通常有个筛选标准：看看项目是否对主流程产生影响，考虑到一些关键性的修改对项目的影响，我们有以下几个比较主要的关注点：

设计是否满足系统需求，包括功能、性能、兼容性、可靠性等；

涉及新技术基础组件的引入；

核心业务流程变动；

与核心业务系统交互变动；

与外部系统交互变动；

主要系统的边界划分；

是否符合公司制定的架构标准规范；

是否符合安全规范；

脱离实际情况的容量规划；

是否涉及系统重复建设问题

　　美团外卖资深技术专家曹振团：

架构通常是为了解决系统的高并发、高性能、高可用的问题，结合业务特点在研发资源、排期、技术方案之间做平衡。一个“坏”的架构则破坏了这种平衡，比如：由于工期紧张而引入了一个自己并不能把控的技术方案，为系统的稳定性埋下了雷。

有一个简单的判断标准是：当采用这个架构后在未来多长时间或几倍增量下需要调整架构。基本上要求至少在未来的半年到一年内或2倍增量下不需要调整架构。如果架构设计评审不符合这个标准就要及时重新设计或调整。

　　京东商城研发部架构师林世洪：

凡事预则立，不预则废，需要给架构设计者一个设计原则，必须遵守，即did原则：design 20倍体量，implement 3倍的体量，deploy 1.5倍的体量。这里的体量结合非功能要求来说，可以是吞吐量、存储容量等。

要贯彻这个原则，需要对业务量的发展有预判，对系统处理能力有评估，对设计方案有评审，对资源申请有审核，对线上资源利用率有监督，这些流程对应的手段很多，这里不多赘述。

除了体量之外，还是一个先进性跟踪的问题，架构设计上如果过于超前，对于技术开发人员要求较高，往往需要专业的团队，这样成本会有相应的增加。如果技术开发人员的水平跟不上的话，就会影响业务的变化。

　　架构团队的思考

　　阿里巴巴速卖通技术部总监郭东白：

构建大团队的时候不希望出现匹夫之勇来打仗，现在modern打仗不能靠匹夫之勇，你其实是希望设计一套系统能够让所有人一起创新，第一要创新，第二要集体创新，即democratic team，每个同学都应该赋能给他，甚至一个小兵也可以协助你打仗，而不是只有两个将军打仗。

　　Twitter机器学习平台组负责人郭晓江：

机器学习在业界应用的两大目标是规模化(Scalability)和灵活性(Flexibility)。规模化是系统方面的要求，强调高并发、稳定性、高可复用性等，是应用到产品中的关键；而灵活性是要求能够快速迭代，不断尝试新的算法。

组织结构上一般会有两个平行的团队，一个偏重算法研究，比如Google和Facebook都有专门做机器学习研究的团队，主要是解决灵活性的问题；另一个团队是偏重机器学习平台，和产品应用结合的比较紧密，主要解决规模化的问题。

　　杭州征数技术合伙人&CTO王福强：