架构团队的处世之道
《架构即未来》《架构真经》两本经典架构书里都对架构的原则展开了很多，但都是偏向技术层面的。这里我要另辟蹊径，说的不只是架构本身的原则，还有架构团队如何玩得转的原则，跟上文架构团队的定位是戚戚相关的：
- 可抽象的有基础组件面相的实现尽量由架构统一实现，然后推动各系统使用通用的基础框架，而不是每个系统写。比如加解密，比如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年的一篇题为<Should We Kill The Architecture Review Board?>的文章...WTF...
传送门: 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管理者如何使用好架构团队这把尖刀的事情。论点太多没有再花时间找到他们的内在联系做个归集，还请各位看客多担待，搁笔。
