文章插图
从上图可以看出架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域） 。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速的反馈，产品不满足最终用户需求，继续看下面两个图：
文章插图
文章插图
第一个图是讲最小可用产品（Minimum Viable Product，MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品 。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题 。注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险 。
另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的
给大家推荐两篇不错的微信文章（微信不能插入链接，根据题目google下即可）：
- 58同城沈剑：好的架构源于不停地衍变，而非设计
- 宜人贷系统架构–高并发下的进化之路
构建闭环反馈架构
文章插图
第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递 。
文章插图
文章插图
第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环 。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节） 。有两种化这样讲的：
- no measurement, no improvement没有测量，就没有改进和提升
- What your measure is what you get你测量什么，就得到什么
这篇文章提出了度量驱动开发的理念，即所谓MDD，在系统，应用和业务，通过三级监控，构建三个反馈环，在监控测量基础上持续改进系统和架构，我最近也在参考这个理念设计一个电商平台的技术架构，见下图：
文章插图
这是一个电商平台的架构，整个体现了闭环架构的思想，右侧是整个平台的反馈监控环节 。具体如下：
- 系统层监控计算网络存储，构建系统层的反馈环
- 应用服务层，监控业务、应用、服务，甚至整个研发流程，构建应用和服务层的反馈环
- 客户体验层，监控端用户和分析网站用户的行为，构建和客户的反馈环
文章插图
收集->测量->调整->闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测 。
文章插图
第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化 。这点是最难的，一般和企业人才密度有关 。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化 。
推荐阅读
- 工程师开发了一种全新的量子计算架构
- 哪种运动方法减肥最快呢?
- 大门|风水大师谈公司搬迁有什么风水讲究
- 蜂蜜蛋清做面膜功效有什么呢？
- 金秋十月万人品茶,上海市工艺美术大师蒋国兴田申原创的紫砂壶圣地十月近日
- 案例 | 中小银行分布式架构探索与实践
- Tomcat 系统架构与原理剖析
- 身为高级架构师是一种什么体验？
- Serverless无服务器架构详解
- 纳粹月球基地 纳粹德国月球基地