扩展性预期
确保系统的架构和设计可以随着业务的发展而扩展，需要在"业务需要"发生之前就想好，远在业务部门的预测超过平台的容量之前，就已经对如何扩展系统深思熟虑了。 软件的整个生命周期中，开发交付其实只是一小部分，后期的需求变更、维护升级、重构优化才是主旋律。那么多考虑软件的扩展性和未来预期是很有必要的，作为架构师至少看得到半年后的规模扩展吧？
标准规范
负责各项标准、规范、流程的设定和推行。这是架构团队的一个重要职能，也是最容易被忽视的。技术手段并不是所有的问题的最佳解决方案，很多场景通过推行标准规范就可以达到不错的预期效果。
比如编码规范，可以通过投入大量人力来开发IDE/代码库的插件进行代码规范的自动检查，再需要不断的测试来验证这个插件的可靠性。通过编程考试或者平时的review来强化这一规范的落地，再加上编程规范的不断宣导可以达到至少八成的效果，何乐而不为，最后那两成效果就放到公司真到一定的级别了考虑技术实吧。再比如架构组研发了统一的基础日志组件，可以规范日志格式、掩码敏感信息、自动截取/压缩超长日志报文等功能，这种组件就应该作为标准全员推广。
拆解抽象
在参与业务迭代的过程中，能够抽丝剥茧(拆解)，发现需求、编码、测试、发布等环节中的痛点、共性点或未来瓶颈点等进行抽象、实现并最终推广全员。在代码层面也适用，拆解交织繁杂的代码逻辑，抽象出基础公共模块。都是架构团队的基本技能。
举例来说，架构师经常会参加各种各样的评审，对那些常见的review comments，五花八门的自造轮子，一旦发现就要有这种敏感度需要制定标准规范或者研发统一的组件了。
技术宽度
架构师需要足够的技术宽度，从软件到硬件，从语言到操作系统，从编码到测试，从运维到安全，从拥抱开源到自造轮子都要有所涉猎。有个比喻，说架构师需要具备某种上帝视角，来俯视软件产品的诞生、成长、重构整个生命过程。而且架构师要有空杯心态，若学习的技术越多，就觉得自己的水平越高，那基本不会是一个合格的架构师；实际应该是越学习觉得自己不懂的越多。
另外，特别要有面对疑难杂症的自信和能力，为业务团队提供强力的技术输出。因为疑难杂症的最后一关就只有架构团队。
协调领导
架构团队绝对不是偏安一角写写基础组件，既然要制定标准，推行规范，那就必须与其他团队进行协作，需要征得他们的合作态度，才能顺畅的推行，这个靠架构团队在技术和业务上的影响力来驱动协调基本可以办到。但在某些情况下，需要一些强制的手段，比如设计文档的强制评审，那就必须赋权给架构团队一定的权力，或者在一些矩阵型组织里架构师就是拥有技术的绝对权威，这个就是领导力。
深入业务
技术的存在就是为业务服务的，脱离业务的架构都是耍流氓，99%的情况下这句话都没毛病。有些技术人有严重的重技术轻业务思想，这种人除非真的是钻研技术的一把好手，可能不善言谈不善沟通（笔者本人是可以接受的），但是架构团队里这种人不能多。后文我们会详细讨论下架构团队和业务团队的协作问题。
创新突破
架构团队在IT内部必须是第一生产力，不管是单兵作战还是团战能力。除了过硬的基本功外，不断的学习和寻求技术上的突破，是贯穿架构团队始终的一个Object。前人已经累计了很多经典优秀的平台、框架或思想作为传承，我们可以继承但绝不能守旧。
在学术研究中，“创新”一词用来表示团队有增加值的产出。而有些创新调研项目很多时候并不会有实际的产出，甚至更糟糕些，会产生许多沉没成本，但这都不是阻碍创新的借口。创新是架构团队延续生命力的最佳营养品和必要条件。可以想象没有创新突破，架构团队完全可以就地解散。
架构团队的处世之道
《架构即未来》《架构真经》两本经典架构书里都对架构的原则展开了很多，但都是偏向技术层面的。这里我要另辟蹊径，说的不只是架构本身的原则，还有架构团队如何玩得转的原则，跟上文架构团队的定位是戚戚相关的：
可抽象的有基础组件面相的实现尽量由架构统一实现，然后推动各系统使用通用的基础框架，而不是每个系统写。比如加解密，比如HTTP客户端，并不是所有人对加密的填充、编码、提供者都有清晰的认识，也并不是所有人对HTTP客户端里的超时时间、DEFAULT_MAX_PER_ROUTE、SSL配置等都了解，专业的事情交给相对更加专业的人去实现。
《架构即未来》里提到一条“要使用成熟的技术”，个人延伸一下：不仅如此还要使用尽量统一的技术，尽量统一的代码层级结构（起码有一些约定俗成的层级）。有人用Gson, fastjson，jackson的比比皆是，hibernate/mybatis也是各有所好。都是成熟的技术，但是不统一，导致了不管是矩阵式还是敏捷式团队，同一个人维护不同系统时，必然会有一些不适应，需要思维的跳跃，无形的增加很多非必要成本；再者不同技术的引入可能会增加更多的BUG或管控风险和排障的难度。
常见的代码层级结构 controller->business->service->dao，在一些人的项目里 business变成了handler, service变成了proxy，怎么都会让人无所适从吧？
微服务体系内的单体系统必须做好自我保护，这是架构团队理应对IT产品做出的承诺。服务提供方根据需求说明设计并承诺了一个服务接口定义，如果调用方只管调用服务方只管实现，一个不慎就会把接口设计成一颗雷。
比如会员系统提供用户基本信息的查询接口，这个接口提供的用户信息“基本”的边界在哪里，单表查询也就罢了，如果需要多表连接查询呢？有些人喜欢把这个接口做的大而全，很灵活，比如在最基础的用户信息之上，会附加一些其他字段如QQ号，工作单位，年收入等等算不上基本信息的信息，只要调用方多传入一些参数即可。确实感觉灵活了，但为此服务方不得不做各种的入参判断和SQL拼接，最差的情况可能需要关联用户的所有相关表，性能差到冰点不用说，对系统本身的吞吐量和并发能力都会有特别大的影响。这就是系统没有自我保护好。因为并不是说系统有什么BUG， 但是因为这个灵活度引入了极大的性能隐患。
再比如用户列表的查询，服务使用方传入参数作为WHERE条件进行过滤，如果使用方什么都不传，这个查询接口基本等同于全表查询的脱库了。这时候必挂无疑，那么是不是应该加上分页，或者最大结果集的限定条件进行自我保护呢？
架构团队的任何框架、组件级别的需求，都应该做好充分调研，不能闭门造车自己臆想需求。技术人很少能做到乔帮主似的，对方不知道自己想要什么由我来告诉你应该用什么；再者如果臆想的实现最终发现并不适用又耗费了大量成本，或多或少总会被别的团队看轻吧，身为架构师如何能忍？而且把需求调研沟通清楚，未来推广也会得到大家的支持，很简单，因为需求是大家一起提出来的。
任何的标准规范的推行、框架组件的立项、实现和发布需要获得高层的充分授权，也需要与重要干系人（比如团队或职能部门负责人）提前沟通好，减少推动阻力，获得推行计划的承诺。比如为了线上系统的监控和排障考虑，需要有健康检查、规范的日志格式等，这些业务需求之外的任务势必会增加业务团队的负担，如果没有从上至下的强制性推动，很难有实际进展。架构团队万勿把自身置为其他团队的对立面。
在迭代周期内的重要环节都需要有架构团队(或架构评审委员会,后文会详说)的深度参与，包括需求调研，接口/数据库设计评审，代码评审，上线评审等。这个对于创业公司起步阶段特别有益，因为在规范和标准没有在IT内部形成一种文化驱动的高度，同一个事情被不同的人做出来完全是千人千面，那对于一个组织来说，这种不可控是很危险的。
特别注意，这些参与绝对不能以俯视批判挑毛病的角度展开，而应该以合作共赢建议的方式展开。当然如果是无法妥协的双方起冲突的问题必须通过授权来强制修正。
《架构及未来》把监控设计放在15条原则的第4条，它也是笔者推崇的一个重要原则。监控可以把我们整个系统的健康度清晰的展示出来，两眼一抹黑只是另一种形式的掩耳盗铃。监控的颗粒度细化到什么程度需要视团队成熟度有所不同，不在本文讨论范围。重要的是，监控设计应该在系统的初期概要设计期间作为非功能性需求就考虑进去。
再做个提醒，监控可以视作运维工作的一部分，所以在前期做架构设计的时候，一些运维工作也应该记录Involve进来。文件传输到底选择FTP还是接口传输，有没有考虑运维带宽、断点续传、CDN等问题呢？
尽量通过工程化来替代人工。工程化就是Engineering，软件工程化是个比较抽象的概念，就是把软件按照工程的方式进行开发维护。这里我们说的工程化可以简单理解成工具化，自动化的动手文化。当然这里的“动手”不是打架，而是敲代码，Just show me the code。我们的自动化运维、实时监控告警、自动化发布、智能排障，都是工程化手段来解放人力。这也是驱使团队不断进步的一种方式，不能陷在一些重复劳动的舒适区里，要不断的想办法改进工作效率和质量。
架构团队出品的任何产品、流程必须建立最严格的标准，比如代码质量、性能指标、监控指标、高可用性、可扩展性等。在一个大的组织架构里建立信任是个很慢的过程，但是失去信任却可能是瞬间的。“架构出品，必属精品”应该是架构团队的一块金字招牌，必须保护好。Besides, 架构团队要有比较优秀的宣传能力，能够把自己的产品包装成一个高附加值的优秀作品，好像你不用就会懊恼一辈子似的，当然这一切都是必须是真实的不能盲目夸大。因为笔者是实实在在看过不少架构师撰写的产品发布邮件，写的不痛不痒，平平淡淡，完全激不起想要试用一下的冲动，还何谈推广。
线上系统特别注意惊群效应的影响。比如缓存失效后，如何解决惊群效应带来的数据库或者微服务化链路尾端服务的压力骤增的问题。这个是技术问题。比如秒杀场景下会有平时百倍千倍万倍的流量打进来，服务器资源会被瞬间消耗殆尽导致崩溃和瘫痪，这就不仅仅是技术问题了，还有与前线业务方协调沟通的问题，这种活动必须提前通知到IT。
来自维基百科：
Thundering herd problem惊群问题是计算机科学中，当许多进程等待一个事件，事件发生后所有这些进程被唤醒，而只有一个进程能获得CPU执行权，其他进程又得被阻塞，这造成了严重的系统上下文切换代价。C10K/C10M问题都与这个相关。
还有两个类似的术语一并介绍下：
“Slashdot effect点杠效应”这个词指的是当著名新闻网站Slashdot在一篇有趣的文章里报道了一个网站后许多人纷至沓来把它几乎挤爆的现象。后来被列入其他著名网站后所发生的类似现象也用这个词来称呼了。这个词和Flash crowd这个更一般性、更合适的词对应。
“Flash crowd突发访问拥堵”这个词是1973年Larry Niven在他的短篇科幻小说Flash Crowd中生造出来的。小说预言了廉价的瞬移技术会使得一大群人都会传送到有趣的新闻故事发生的地方从而导致拥堵。20年后，这个词在互联网上被广泛用于指当网站有了能吸引许多人的东西之后其服务器系统资源使用量成指数增长。在此之前，Alfred Bester在他的小说The Stars My Destination中也预计到了这种效应。
架构团队 versus 业务团队
单独拎出来这两个团队的相处之道并不是说这两个团队有什么不得了的冲突（相较于开发vs测试，开发vs运维，测试vs运维），只是只要有协作就会出现问题，但是这个冲突并不难解决。其实上文也断断续续提到一些原则，但终极方案无外乎两个词：尊重和信任。
架构要得到尊重就要在技术上保持先进性，且必须对业务有一定的深入度；业务要得到尊重那就除了要在业务上有深刻理解，在与技术的结合上也必须有自己的思考。而事关信任，双方只要在自己发布的产品上倾注足够的专注度，展示了自己的态度，最后又保证了质量和口碑，就会逐步建立起信任关系。
架构评审委员会ARC
定义
七拼八凑好不容易整理了一个个人还算满意的定义：架构评审委员会Architect Review Committee作为IT的一个治理监管机构，有权力确保IT运转在整个架构生态内保持一致，提高IT的产品质量，并最终与公司的目标、战略达成一致。
《架构即未来》一书中架构评审委员会的缩写是AR B(oard)，笔者选择了ARC纯粹是为了好记好发音。其实ARB才是业界主流说法...
那为什么要有ARC？是否必要呢？那是必然的。上图中归纳的5大块：技术、流程、标准、质量和创新都在ARC的辖内，且ARC有绝对的话语权提供决策结果，另外ARC也是捏合架构团队（落地）、PMO（项目管理办公室）和业务团队的关键机构。
不能再搞笑的是笔者竟然先看到了微软2012年的一篇题为
传送门: https://blogs.msdn.microsoft.com/nickmalik/2012/04/17/should-we-kill-the-architecture-review-board/
我简单给大家归纳一下文中表达的意思：按照COBIT标准IT的治理体系应该有三个委员会：架构Arch委员会、策略Strategy委员会和指导Steering委员会 ，而架构委员会只对项目工程有话语权，指导委员会却对IT投资、预算和交付等有话语权，一句话就是管钱袋子的定规则，架构委员会干不过指导委员会。既然架构委员会说了不算那就不要了，成立一个CIO牵头的说了算的IT治理委员会，来完成满足COBIT标准的事情。标题说的那么吓人说Kill掉，其实也就是因为微软里的ARB说了不算，对于决策权这个在笔者的定义里已经标明了。
咱们中小型公司没有也不需要微软那么大的标准体系，当然不关心那么多道道，三者合一就叫ARC来行使所有IT治理框架需要的所有职能。
创业公司如果有如下困扰，并开始越来越明显的影响到IT正常的运作，那么贵公司应该考虑成立ARC：
软件产品的质量不可控，时常发生缺陷Escapse到线上生产环境的事件；
职能团队、业务团队、项目团队之间各自为战，没有统一的规范，代码、接口、数据库千变万化，比如那些三无项目：无注释无文档无单元测试；
有各种各样的阻力或者痼疾导致无法推动持续交付/持续部署的进行；
研发团队与测试团队之间脱节，比如研发不自测就提交测试，测试团队在需求阶段未被拉入，导致测试案例缺失等；
IT产品整体在架构、治理方面没有人或者只有CTO一人负责，导致IT团队对产品的远期路线线缺乏足够的认识，仅仅满足于实现业务功能而已；
公司已经出具规模了，但非功能性需求还从来没有被正式提出来过，性能、安全等。
职能范围
提高软件产品的质量
规划，设计和实施IT基础设施和应用程序健壮的、可扩展的、可靠安全的架构
定义架构设计的标准，政策和总体原则
建立和推广优秀架构设计的最佳实践
创建架构的路线图：持续交付、灰度发布、服务治理、智能监控等等
负责软件产品在各个过程环节的评审，包括但不限于可行性、需求、接口、数据库、生产发布等的评审
保持对新技术、新框架、新思想的敏感度和足够的深入度，方能从容应对未来可能的升级
必须保证拥有或者领导权或者充分的授权
驱动IT产品的创新和升级，补齐短板，但是要做好与常规任务的权衡
工作原则
严格坚持统一的评审标准，坚决不能存在双标情况，否则会降低ARC的权威性；
确保ARC过程得到足够的尊重，且ARC一旦产生结论则被视为最终决定。若最终评审结果得不到修正，浪费大家的时间，ARC失去公信力，标准规范也就失去了意义。
不能以任何理由，比如常见的项目周期紧就不要评审了之类的借口，随随便便绕开ARC过程。一旦开了头就会有其他团队的效仿并绕开，最终ARC的价值就会不断被迅速削弱。
ARC组织内必须固定一部分永久性的委员，可以是有话语权有地位的领导（CTO，总监，VP），可以是专业或技术上有威望的专家（架构师，业务负责人等），这部分的委员是保证ARC流程是可以容易下达传导的。其他再配置一些某些专长的候选人作为轮换委员，作为ARC过程的补充力量，毕竟ARC组织的人数相比整个IT组织是远不够用的。
发生如下情况说明成员需要调整了：
a. 时不时的发生ARC成员之间的意见不一致, 总有一方要被踢出去，保证内部的绝对统一；
b. 发现成员有滥用权力、刁难、凭个人好恶等违反公司利益的方式做事，必须剔除并作为长期关注对象，以防做出其他对公司有损害的事情；
c. ARC过程经常被合理挑战，而且挑战的结果是对的，这个人可以考虑被培养并吸纳；
ARC的大部分活动实际上对于每个成员来说是一种额外的工作，在保证自己日常工作的情况下还要随时出席各种的ARC会议，这对ARC成员的日常工作规划是个考验，所以ARC过程和会议都要尽可能的准备充分和直接了当。比如代码接口评审的代码必须提前准备好演示IDE环境，数据库评审提前准备好PDM, 会议过程要足够的FOCUS，不能太发散导致会议时间过长。
某些时候不得不在ARC的权威性和业务排期之间做选择的时候，一定要抛给决策高层(比如CTO)来做出决定，ARC不能站出来当"恶人"。反过来，如果ARC对业务团队的资源占用经常被抱怨，那必须考虑重新调整轻量化ARC的过程了。
终于写完了，基本都是大段大段的文字，配图都不好配，确实不如贴代码来的舒爽，可能大家会看的比较累。我就再总结一下，其实主要就说了一下架构团队应该如何以及如何更好的自处或他处，IT管理者如何使用好架构团队这把尖刀的事情。论点太多没有再花时间找到他们的内在联系做个归集，还请各位看客多担待，搁笔。
（欢迎加入蚂蚁金服）