《《架构师》2016年3月》读后感2300字
书名：架构师（2016.03）
类型：计算机类技术博客
编者简介：infoQ
本书主要讲述了云端服务相关的内容，主要内容包括：
1. spinnaker布署工具
2. 几种常见的架构类型
3. 问答系统的前世今生
4. 初创公司应该如何选择技术架构
1. Spinnaker介绍
Spinnaker 是 Netflix 的开源项目，是一个持续交付平台，它定位于将产品快速且持续的部署到多种云平台上。Spinnaker 通过将发布和各个云平台解耦，来将部署流程流水线化，从而降低平台迁移或多云品台部署应用的复杂度，它本身内部支持 Google、AWS EC2、Microsoft Azure、Kubernetes和 OpenStack 等云平台，并且它可以无缝集成其他持续集成（CI）流程，如 git、Jenkins、Travis CI、Docker registry、cron 调度器等。简而言之，Spinnaker 是致力于提供在多种平台上实现开箱即用的集群管理和部署功能的平台。
2. 几种常见的架构原则和模式
文中分析了四种架构：分析了4种常用的软件架构模式，分别是分层架构、事件驱动架构、微内核架构和微服务架构。
2.1 分层架构
分层架构是最常见的架构，也被称为n层架构。大多数应用程序使用3-4层。有太多层的设计会很糟糕，将导致复杂度的上升，因为我们必须维护每一层。在传统的分层架构中，分层包括表现层、业务或者服务层，以及数据访问。
分层架构中的核心概念是管理依赖。如果我们使用依赖倒置原则和测试驱动开发(Test Driven Development)，我们的架构会有更好的健壮性。
分层架构中的一个重要的概念就是分层的开闭原则。如果某层是关闭的，那么每个请求都要经过着一层。
分层架构是SOLID原则的通用架构，当我们不确定哪种架构更合适的时候，分层架构将是一个很好的起点。我们需要注意防止架构陷入污水池反模式。这种反模式描述了请求经过分层，但没做任何事或者只处理了很少的事。如果我们的请求经过所有分层而没有做任何事，这就是污水池反模式的征兆。
2.2 事件驱动架构
事件驱动架构（Event Driven Architecture）是一种流行的分布式异步架构模式，用于创建可伸缩的应用程序。事件驱动架构可以与调停者拓扑（Mediator Topology）或者代理者拓扑（Broker Topology）一起使用。
调停者拓扑需要编排多种事件。比如在交易系统中，每个请求流程必须经过特定的步骤，如验证、订单、配送，以及通知买家等。在这些步骤中，有些可以手动完成，有些可以并行完成。
调停者架构主要包含4种组件，事件队列（Event Queue）、调停者（Mediator）、事件通道（Event Channel）和事件处理器（Event Processor）。
不像调停者拓扑，代理者拓扑不使用任何集中的编排，而是在事件处理器之间使用简单的队列或者集线器，事件处理器知道处理事件的下一个事件处理器。
2.3 微内核架构
微内核架构（Microkernel architecture）模式也被称为插件架构（plugin architecture）模式。这是产品型应用程序的理想模式，由两部分组成：核心系统和插件模块。核心系统通常包含最小的业务逻辑，并确保能够加载、卸载和运行应用所需的插件。许多操作系统使用这种模式，因此得名微内核。
插件彼此独立，因此解偶。核心系统持有注册器，插件将自己注册其上，因此核心系统知道哪里可以找到它们以及如何运行它们。这种模式非常适合桌面应用程序，但是也可以在Web应用程序中使用。
2.4 微服务架构
微服务架构是一项在云中部署应用和服务的新技术。最重要的概念是包含业务逻辑和处理流程的服务组件（Service Component）。
服务组件是解耦的、分布式的、彼此独立的，并且可以使用已知协议来访问。关键在于该服务可以在自己的程序中运行。
3. 问答系统
问答系统算是人工智能领域的内容了，这两年人工智能很火，而问答系统也是相当的常见，各大互联网公司都推出了自己的智能音箱，比如Google的Google Home，亚马逊的echo，百度的小度在家；阿里的天猫精灵；小米的小米AI，以及腾讯的腾讯听听等等。
这些智能音箱孰优孰劣，我也没有全部体验过，不好置评。不过这些智能音箱肯定都是内置了问答系统的。
对于一个普通的事情而言，我们想要全面了解这件事情的话，就需要从5W1H这六个角度来分析问题。同样，对于问答系统而言，也是面临如何解答这六个角度的问题。
问答系统学界面临的三大类难题便是：What类型问题、How类型问题、Why类型问题。
4. 杨波对于架构的理解
我觉得本文中最有含量的当属这部分内容了。
杨波具有超过10年的互联网分布式系统研发和架构经验，曾先后就职于：eBay中国研发中心（eBay CDC），任资深研发工程师，参与亿贝开放API平台研发，携程旅游网（Ctrip），任技术研发总监，主导携程大规模SOA体系建设，唯品会（VIPShop），任资深云平台架构师，负责容器PaaS平台的调研和架构，目前就职于法国LVMH集团中国区的垂直电商部门，任职电商首席架构师，帮助传统IT向互联网转型。
他主要讲述了自己对架构的理解；架构应该是逐步演化的，而非一蹴而就的；然后重点介绍了如何构建闭环反馈架构（这部分内容是我觉得最有价值的一部分）。
他认为系统架构的目标是解决利益相关者的关注点。
架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。
在构建闭环反馈架构时，他介绍了三条途径：
1. 第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。
2. 第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。
3. 第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化。
当然他还推荐了几篇架构相关的文章，这里就不多做介绍了。
本文整体感觉还是挺有质量的，值得一读。
关于专业书，还是那句话：纸上得来终觉浅，觉知此事要躬行。
完~