《架构师》期刊摘要（2016年）二

一、

    1、分层架构

    分层架构是最常用的架构，也被称为n层架构；多年来，许多企业和公司都在他们的项目中使用这种架构，它已经几乎称为事实标准，因此被大多数架构师、开发者、软件设计者所熟知。

    分层架构中的核心概念是管理依赖。如果我们使用依赖倒置原则和测试驱动开发（Test Driven Development）,我们的架构会有更好的健壮性。因为，我们要保证所有可能的用例都有测试用例。（备注：依赖倒置原则是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。一种面向对象的设计原则。）

 

    我们需要这样的冗余，即使业务层没有处理业务规则，也要通过业务层调用数据层，这叫分层隔离。对于某些功能，如果我们从表现层直接访问数据层，那么数据层后续的任何变动都将影响到业务层和表现层。（表现层、业务层、服务层、持久层）分层架构中的一个重要的概念就是分层的开闭原则。如果某层是关闭的，那么每个请求都要经过这一层；相反，如果该层是开放的，那么请求可以绕过这一层，直接到下一层。

 

    分层隔离有利于降低整个应用程序的复杂度。某些功能并不需要经过每一层，这时我们需要根据开闭原则来简化实现。分层架构师SOLID原则的通用架构，当我们不确定哪种架构更合适的时候，分层架构将是一个很好的起点。我们需要注意防止架构陷入污水池反模式。这种反模式模式了请求经过分层，但没有做任何或者只处理了很少的事情。我们的请求经过所有分层而没有做任何事情，这就是污水池反模式的征兆。如果20%的请求只是经过各层、而80%的请求实际做事，这还好，如果这个比率不是这样的，那么我们已经患上反模式综合征。（备注：SOLID原则是面向对象设计的一些参考性原则，S.单一职能原则，O.开闭原则--对扩展开放、对修改关闭，L.里氏替换原则--子类实例应该可以完全替换父类实例，I.接口分离原则--接口应该按照特性分离而不是使用单一接口，D.依赖倒置原则--高层模块不应该依赖于底层模块、而是都依赖于抽象）

 

    此外，分层架构可以演变为巨石应用（Monolith，单体），导致代码库难以维护。分层架构分析：

    1）敏捷性：总体敏捷性是指不断变化的环境做出反应的能力。由于其整体风格（Monolith）的性质，可能会变得难以应对通过所有层的变化，开发者需要注意依赖性和分层分离。

    2）易于部署：大型应用程序的部署会是个麻烦。一个小需求，可能需要部署整个应用程序。如果能做好持续交付，可能会有所帮助。

    3）可测试性：使用Mocking和Faking，每一层可以独立测试，因此测试上很容易。

    4）性能：虽然分层应用程序表现良好，但是因为请求需要经过多个分层，可能会存在性能问题。

    5）可伸缩性： 因为耦合太紧以及整体风格的天生特质，很难对分层应用程序进行伸缩。然而，如果分层能够被构建为独立的部署，还是可以具备伸缩能力的。但是，这样做的代价可能很昂贵。（比如前后端分离，面向服务的设计）

    6）易于开发：这种模式特别易于开发。许多企业采用这种模式。（本人观点：易于开发的原因可能是应用架构分层清晰，职能界定清晰，规范化，在代码本体上，就已经面向组件化。）

 

    2、事件驱动架构

    事件驱动架构是一种流行的分布式异步架构模式，用于创建可伸缩的应用程序。这种模式是自适应的，可用于小规模或者大规模的应用程序。事件驱动架构可以与“调停者拓扑（Mediator）”、“代理这拓扑（Broker）”一起使用。理解拓扑的差异，为应用程序选择正确的拓扑是必不可少的。（备注：事件驱动与分层，并不矛盾，分层通常关注在单体内部，即面向组件内部；事件驱动则是面向服务或者代理的，用于解耦服务或者组件之间的关系；这两者并不是对立的。）

 

    调停者拓扑：通常，架构主要包含四种组件，事件队列（Event Queue）、调停者（Mediator）、事件通道（Event Channel）和事件处理器（Event Processor）。客户端创建事件，并将其发送到事件队列，调停者接收事件并将其传递给事件通道，事件通道将事件传递给处理器，事件最终由事件处理器处理完成。（大家熟悉的SOA架构中，ESB，调停者本身需要对事件进行编排）

    事件调停者不会处理也不知道任何业务逻辑，它只编排事件。事件调停者知道每种事件类型的必要步骤。业务逻辑或者处理发生在事件处理器中，事件通道、消息队列或者消息主题用于传递事件给事件处理器。事件处理器是自包含和独立的，解耦于架构。理想情况下，每种事件处理器应只负责处理一种事件类型。

    通常，企业服务总线、队列或者集线器可以用作事件调停者。正确选择技术和实现能够减低风险。

 

    代理者拓扑：不像调停者拓扑，代理者拓扑不适用任何集中的编排，而是在事件处理器之间使用简单的队列或者集线器，事件处理器知道处理事件的下一个事件处理器。（有点类似于pipeline，Broker位于顶端）

    因其分布式和异步的特质，事件驱动架构的实现相对复杂。我们需要面对很多问题，比如网络分区、调停者失败、重新链接逻辑等。由于这是一个分布式且异步的模式，如果你需要事务，那就麻烦了，你得需要一个事务协调器。分布式系统中的事务非常难以管理，很难找到标准的工作单位模式。另一个充满挑战的概念是契约，架构师声称服务的契约应该预先定义，而应变则是非常昂贵的。

 

    事件驱动架构分析：

    1）敏捷性：由于事件与事件处理器之间解耦，并且可独立维护，因为这种模式的敏捷性很高。变化可以快速、轻松地完成，而不会影响整个系统。

    2）易于部署：由于架构是解耦的，因此很容易部署。组件可以独立部署，并且可以在调停者上注册。部署在代理者拓扑上也相当简单。

    3）可测试性：虽然独立测试组件很容易，但测试整个应用程序很有挑战。因此端到端的测试是很难的。

    4）性能：事件驱动架构性能非常好，因为它是异步的。此外，事件通道和时间处理器可以并行工作，因为它们是解耦的。

    5）可伸缩性：事件驱动架构的可伸缩性非常好，因为组件之间的解耦，组件可以独立扩展。

    6）易于开发：这种架构的开发不是很容易。需要明确定义契约，错误处理和重试机制得处理得当。

 

    3、微内核服务（非微服务）

    微内核架构模式也被称为插件架构（plugin）模式。这事产品型应用程序的理想模式（平台化的、集成式的），由两部分组成：核心系统和插件模块。核心系统通常包含最小的业务逻辑，并确保能够加载、卸载和运行应用所需的插件。许多操作系统使用这种模式，因此得名为微内核。

    这种模式非常适合桌面应用程序，但是也可以在Web应用程序中使用。

 

    4、微服务架构

    尽管微服务的概念相当新，但是它确实已经快速低吸引了大量的眼球，以替代整体应用和面向服务架构（SOA）（备注：个人认为微服务架构只是SOA架构的延续，概念上仍然基于SOA的核心）。其中一个核心概念是具备高可伸缩性、易于部署和交付的独立部署单元。最重要的概念是包含业务逻辑和处理流程的服务组件（Service Component）。拿捏粒度设计服务组件是必要而且具有挑战性的工作。服务组件是解耦的、分布式的、彼此独立的，并且可以使用已知协议来访问。

 

    微服务的发展是因为整体应用和面向服务应用程序的缺陷。整体应用程序通常包含紧耦合的层、难以交付和部署。比如，如果应用程序总在每次应对变化时垮掉，这事一个因耦合而产生的大问题。微服务将应用程序分解为多个部署单元，因此很容易提升开发和部署能力，以及可测试性。虽然面向服务架构非常强大，具有异构连接和松耦合的特性，但是性价比不高。它很复杂、昂贵，难以理解和实现，通常对于大多数应用程序来说矫枉过正。微服务简化了这种复杂性。

 

    跨服务组件的代码冗余是完全正常的。开发微服务时，为了受益于独立的部署单元，以及更加容易的部署，我们可以违反DRY原则（备注：Don't repeat yourself，不要重复自己）。其中的挑战来自服务组件之间的契约，以及服务组件的可用性。

 

    微服务架构分析：

    1）敏捷性：由于服务组件可以各自独立开发，彼此之间没有耦合，因此微服务架构具有很高的敏捷性。独立部署单元能够应对变化做出迅速的反应。

    2）易于部署：相比其他的架构模式，微服务的优势是服务组件是单独部署的单元。（引入额外的问题，就是完成一个业务特性所涉及到的服务更多，这也会带来服务关系更加复杂）

    3）可测试性：服务组件的测试可以独自完成。微服务的可测试性很高。

    4）性能：依赖于组件和这种特定模式的分布式性质。（服务分裂的维度更大，性能取决于交互协议、服务链深度、异步性等）

    5）可伸缩性：独立部署单元天然具备很好的伸缩性。

    6）易于开发：每个服务组件可以各自独立实现。

《针对架构设计的几个痛点，我总结出的架构原则和模式》（2016年3月）

二、

    系统架构的目标是解决利益相关者的关注点。

    架构师这样定义的：

    1）每个系统都有一个架构

    2）架构由架构元素以及项目之间的关系构成。

    3）系统是为了满足利益相关者（stakeholder）的需求而构建的。

    4）利益想着都有自己的关注点（concerns）。

    5）架构有架构文档描述

    6）架构文档描述了一系列的架构视角

    7）每个视角都解决并且对应到利益相关者的关注点。

 

    架构系统前，架构师的首要任务是尽最大可能找到所有利益相关者，业务方、产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。利益相关者的关注点有可能是冲突的，比如管理员（可管理型）VS 技术方（性能），业务方（多快好省）VS 技术方（可靠稳定），这需要架构师去灵活权衡，如何平衡体现了架构师的水平和价值。

    关于架构的第二定义是说架构主要关注非功能性需求（non-functional requirements），即所谓的-abilities。（Reliability，Reusablility，Manageability，Monitorability，Maintainability，Extensiblity，Understandability，Availability，scalability等等：可靠性，可用性，易用性，稳定性，重用性，可监控性，扩展性；易于拆分，易于部署，易于测试，易于变更，收益比较高）

 

    “架构表示对一个系统的成型起到关键作用的设计决策，架构确定系统形态，这里的关键性可以由变化的成本决定”（Grady Booch，UML创始人之一）：“Architecture represents the significant design decisions that shape a system,where significant is measured by cost of change.”。进一步讲，架构的目的是用于管理复杂性、易变性和不确定，以确保长期的系统演化过程中，一部分架构的变化不会对架构的其他部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁的变化，对应用的其他部分的影响尽可能的小。

 

    架构师要尽可能写代码、做测试，纸上谈兵做架构而后丢给团队的做法非常不靠谱（除非是已经非常清晰而成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造成产品和用户之间不能有效快速的反馈，产品不满足最终用户需求。

    第一个图是讲最小可用产品理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。注意，在系统真正地投入生产使用之前，再好的架构都只能架设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效的减少失败的成本和风险。

 

    先分享一个链接，这几年对我的架构影响最深的一篇文章。这篇文章是关于DevOps的，但对系统架构同样适用：

    http://itrevolution.com/the-three-ways-principles-underpinning-devops/

    这篇文章讲述了企业通向DevOps的三条必经之路，我们来看看这三条道路对架构师的启示。

    第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。

 

   第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节）。有两句话这样讲的：

    1）no measurement，no improvement：没有测量，就没有改进和提升。

    2）What your measure is what you get：你测量什么，就得到什么

    没有监控或者监控不完善的系统相当于裸奔，开车上高速无仪表盘。

 

    第三条道路，鼓励敢于承担责任、冒险试错和持续提升的文化。这点是最难的，一般和企业人才密度有关。工具、技术、流程只是一个公司的冰山浮出水面的部分而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。

 

    架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构，提升整个系统效能。

 

    谈谈微服务，Martin Fowler的两篇关于微服务的，请参考：

    http://martinfowler.com/bliki/MicroservicePrerequisites.html

    http://martinfowler.com/bliki/MicroservicePremium.html

    

    这个图讲什么时候该引入微服务。微服务有额外成本的，需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定因素是系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑。另外补充一点，微服务更多是关于组织和团队，而不是技术。

 

    架构和组织文化关系：

    再谈一下康威定律：Organizations which design system are constrained to produce designs which are copies of the communication structures of these organizations。（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。）

    1）团队是分布式的（分团队的，分层的，分级的），系统架构师单体的，那么开发、测试、部署协调沟通成本很大，严重影响效率，严重时团队之间还容易起冲突。

    2）将单体架构解耦成微服务，每个团队开发、测试和发布自己负责的微服务，互不干扰，系统效率得到提升。

 

    可见，组织和系统架构之间有一个映射关系，两者不对齐就会出现各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功构建高效的系统架构，例如集中式和严格职能（业务，Dev，QA，ops）的企业，很难推行微服务和DevOps，推行Docker/PaasP平台也会比较困难，这样的组织职能之间都倾向于局部优化（local optimization），无法形成有效的合作和闭环。

    反过来也成立的，如果你的系统设计或者架构不支持，那么你就无法建立一个有效的组织，作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。

 

    架构师心态和软技能：

    “如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必有我尚未体会的奥秘，值得加以了解。与人合作最重要的是，重视不同个体的不同心理、情绪和智能，以及个眼中所见的不同世界。与所见略同的人沟通，益处不大，要有分歧才有收获”。《软件架构师的12项修炼》，这本书中三个观点值得每个架构师学习和领会：

    1）soft skills are always hard than hard skills，软技能比硬技能难。

    2）choosing relationship over correctness，注重关系终于谁对谁错。

    3）架构的政治性，在大中型公司里工作的架构师尤其要学习

    政治之的是和他人学做将事情搞定的艺术，架构师一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的、技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品、一波人可以做，另一波人也能做，到底谁能做好，真的不好说，不管谁做，都给业务套上一副手铐。

 

    我对架构师争议主题的看法：

    1）技术和业务的关系

    2）架构师要写代码？

    架构师怎么回答这类问题？一个成熟架构师的口头禅：视情况而定...技术和业务，架构师要理解业务吗？看产品和客户，如果是业务性产品，肯定要理解业务，如果是技术型产品，就不一定。架构师要写代码？也不一定，个人觉得尽可能要写，如果你的写过十年以上代码了，每年不少于2W行，都玩通了，可以不写。领导架构师如果写代码，要把控度，不要一头钻入代码，花大量时间解决细节和复杂性问题，忽视全局和系统性问题。

《每个架构师都应该研究下康威定律》（2016年3月，原文链接）