常用
########


* 微服务的依赖关系可以总结为：上游系统不需要知道下游系统信息，否则请重新审视系统架构。
* 只有对底层知识的原理有了深刻理解，才可能对上面所构建的业务系统有深刻认识。——《软件架构设计》—— 余春龙




响应时间/延迟::

    “我期望这个网站，当每秒处理 200 个并发连接时，90% 的响应时间在 2 秒以内。”



* 响应非常缓慢是最糟糕的故障模式之一。处理系统缓慢要比处理系统快速失败困难得多。



::

    数据存储隔离(DSS, Data Storage Segregation)原则
    单一职责原则(SRP, Single Responsibility Principle)


架构师的核心能力：抽象，提炼，把握关键，预测未来，当然还有沟通（撕逼）



架构实战案例解析
================

架构的本质就是::

    通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化

    首先，架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序。
    其次，架构实现从无序到有序，是通过合理的内部编排实现的，
        基本的手段，就是 “分” 与 “合”，
        先把系统打散，然后将它们重新组合，形成更合理的关系。
        “分” 就是把系统拆分为各个子系统、模块、组件
        “合” 就是基于业务流程和技术手段，把各个组件有机整合在一起。

按照不同的角度，架构可以有很多分类，主要分为::

    1. 业务架构
    2. 应用架构
    3. 技术架构


1. 业务架构::

    讲清楚核心业务的处理过程，定义各个业务模块的相互关系，
    它从概念层面帮助我们理解系统面临哪些问题以及如何处理

2. 应用架构::

    讲清楚系统内部是怎么组织的，有哪些应用，相互间是怎么调用的，
    它从逻辑层面帮助我们理解系统内部是如何分工与协作的。

3. 技术架构::

    讲清楚系统由哪些硬件、操作系统和中间件组成，
    它们是如何和我们开发的应用一起配合，应对各种异常情况，保持系统的稳定可用。
    所以，技术架构从物理层面帮助我们理解系统是如何构造的，以及如何解决稳定性的问题。


* 产品经理是站在用户的角度进行需求分析
* 业务架构师是站在开发者的角度定义系统内部结构

架构图一般来说三个图::

    1. 模块的静态结构图，描述各个模块的层次关系
    2. 模块的动态关系图，比如业务流，数据流，调用关系
    3. 针对核心的场景，补充交互序列图，从具体过程理解交互关系

可扩展架构
----------

系统 = 模块 + 关系

『模块』从扩展性的角度出发::

    首先，我们对模块的要求是：定位明确，概念完整。
    其次，模块还要：自成体系，粒度适中。

『依赖关系』::

    首先，我们希望模块之间的依赖是单向的，尽量避免相互调用
    其次，尽量把网状结构转化为层次结构，模块结构层次化是简化模块依赖关系的有力手段。

扩展性的本质::

    通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。
    具体的架构手段就是按照业务对系统进行拆分和整合：
        通过拆分，实现模块划分；通过整合，优化模块依赖关系。


打造可扩展的模块体系：模块拆分::

    拆分有两种方式：水平拆分和垂直拆分
    先考虑垂直拆分，从大方向上，把不同业务给区分清楚，然后再针对具体业务，按照业务处理流程进行水平拆分

打造可扩展的模块体系：模块整合::

    整合也有两种好的手段：通用化和平台化

    通用化指的是通过抽象设计，让一个模块具备通用的能力，能够替代多个类似功能的模块。
        通过模块通用化，模块的数量减少了，模块的定位更清晰，概念更完整，职责更聚焦。
        在实践中，当不同业务线对某个功能需求比较类似时，我们经常会使用这个手段。
    平台化是把定位相同的模块组织在一起，以组团的方式对外提供服务。
        业务平台化是模块依赖关系层次化的一个特例，只是它偏向于基础能力，
        在实践中，当业务线很多，业务规则很复杂时，我们经常把底层业务能力抽取出来，进行平台化处理。


同一层的模块可以相互调用吗::

    基础模块不调用其他基础模块，比如会员服务不调用商品服务，它们相互之间应该是正交的。
    上层的聚合服务可以相互调用，组成更大的聚合服务。

架构的演变
==========

.. note:: 在单体架构中，模块结构是否合理，很大程度上依赖于开发者的个人水平。

分布式架构适用于业务相关性低、耦合少的业务系统。举个例子，企业内部的管理系统，分别服务于不同的职能部门，比如财务系统和 HR 系统，就比较适合按照分布式架构去落地。

SOA 架构（Service Oriented Architecture）是一种面向服务的架构，它的发展经历了两个阶段：传统的 SOA 架构，它解决的是企业内部大量异构系统集成的问题；新的 SOA 架构，它解决的是系统重复建设的问题。
传统 SOA 架构，它主要用于解决遗留系统的集成问题。
十几年前，两个术语很流行，EAI（enterprise application intergratioin）和 EII (enterprise information intergratioin), 都是为了各个系统打通。
现在互联网企业盖过传统企业，应用都是自己开发，集成没问题，更多考虑系统扩展和复用，能够快。

但两者不同的地方在于，微服务是去中心化的，不需要 SOA 架构中 ESB 的集中管理方式。
微服务强调所谓的哑管道，即客户端可以通过 HTTP 等简单的技术手段，访问微服务，避免重的通信协议和数据编码支持。另一方面，微服务强调智能终端，所有的业务逻辑包含在微服务内部，不需要额外的中间层提供业务规则处理。


中台
====

对于互联网企业来说，有大量微服务做基础，往中台转是改良，目的是更好地衔接前台和后台，实现业务的快速创新；
对于传统企业来说，内部有大量的遗留系统，落地中台是革命，目的是盘活老系统，全面实现企业的数字化转型。

平台很多地方都可以说，比如技术平台，运维平台，只要定位类似，有比较多的内容，都可以号称平台。
中台特指对系统的某些部分进行封装，可以提供企业级业务能力的复用，你可以认为中台是一个特殊的平台。

.. note:: 中台是企业整体能力的快速复用，更重要的是这个理念。

微服务 -> 共享服务 -> 中台，最后实现企业级能力的复用。


可复用架构
==========


落地一个微服务并不难，但要实现能够高度复用的共享服务不容易，在落地过程中，常会有一系列的问题::

    1. 我们事先对服务的边界没有进行很好的划分，结果在落地的过程中，大家反复争论具体功能的归属。
    2. 由于对业务的了解不够深入，我们要么设计不足，导致同一个服务有很多版本；
    3. 要么服务过度设计，实现了一堆永远用不上的功能。

.. note:: 对于落地一个共享服务来说，服务边界的划分和功能的抽象设计是核心服务边界确定了这个服务应该 “做什么”，抽象设计确定了这个服务应该 “怎么做”。

* 完整性原则：要保证服务数据完整、功能全面，这样才能支撑一个完整的业务领域。
* 一致性原则：服务的数据和指责一直，谁拥有较多的数据，谁就负责提供相应的功能
* 正交原则：服务之间可以用数据的依赖关系，但没有接口的调用关系









* https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3