7.3 业务问题
7.3.1 陷阱： 产品定制
销售人员希望软件可以无限定制。
为每个客户定制
永久的功能开关
产品驱动定制化
7.3.2 反模式： 报表
报表是单体架构中意外耦合的好例子。架构师和 DBA 想使用相同的数据库模式来支持记
录和报表系统，但问题是，这种设计既无法优化记录系统，也无法优化报表系统。
7.3.3 陷阱： 规划视野
预算和规划流程通常决定了对假设和早期决策（假设的基础）的需求。然而，不去重新审
视计划，规划范围越大意味着更多决策（或假设）是基于最少量的信息制定的。
8,实践演进式架构
实现演进式架构相关想法所需的工作。
8.1 组织因素
8.1.1 全功能团队
以领域为中心的团队应该是全功能的，这意味着每个项目角色都由该项目组成员承担。
业务分析师,架构师,测试人员,运维人员，数据人员
8.1.2 围绕业务能力组织团队
按照业务能力而非职能来组织团队。
8.1.3 产品高于项目
围绕产品而非项目来组织团队工作
公司能在三个方面实现转变。第一，与项目的生命周期不同，产品
的生命更长久。全功能团队（通常基于康威逆定律）与产品保持联系。第二，每个产品都
有一个负责人，他会主张在体系中使用该产品，并管理其需求。第三，由于是全功能团
队，团队拥有产品所需的各种角色，例如业务分析师、开发人员、质量保障人员、 DBA、
运维人员等
8.1.4 应对外部变化
构建适应度函数来保护架构中的维度免于演进副作用的影响。
8.1.5 团队成员间的连接数
构建小型团队是为了减少沟通连接。并且，为了消除
不同团队间协作所产生的人为摩擦，这些小型团队需要是全功能团队。
8.2 团队的耦合特征
8.2.1 文化
好的架构师会担任领导角色，为开发人员
构建系统确立技术文化和设计方法。
架构师能通过提下列问题了解团队的工程文化。
1是否团队所有人都知道什么是适应度函数，并考虑了新工具或产品选型对演进新适应度
函数的影响？
2.团队是否衡量了系统与所定义的适应度函数的匹配程度？
3.工程师是否理解内聚和耦合？
4.是否讨论了什么领域和技术概念该整合到一起？
5.团队是基于变更能力还是基于他们想学习的技术来选择解决方案的？
6.团队对业务变更如何做出反应？他们是否难于完成小的变更，或在小的业务变更上花费
了太多时间？
8.2.2 试验文化
成功的演进离不开试验
组织可以通过如下几种方式鼓励试验。
1从外部吸收想法
2，鼓励明确的改进
3进行探针试验并稳定下来
4创造创新时间
5 采用基于集合的开发方式
6连接工程师和最终用户
8.3 首席财务官和预算
在演进式架构中，企业架构的一些传统功能必须反映不断变化的优先级，例如预算
在演进式架构中，架构师追求合适的量子大小和对应成本之间的最佳点。
8.4 构建企业适应度函数
在演进式架构中，企业架构师的工作主要围绕着架构指导和企业级适应度函数展开。
演进式架构赋予企业架构师的另一个新职责是定义企业级适应度函数
8.5 从何开始
一些构建演进式架构实践的相关通用策略和理由。
8.5.1 容易实现的目标
如果组织需要早期成功来证明这种方法，架构师可以选择最简单的问题来凸显演进式架构
方法。
8.5.2 最高价值优先
找到系统中最关键的部分，围绕它构建演进行为。
第一，如果架构师确信要实现
演进式架构，那么选择价值最高的部分就表明了决心。第二，对于那些仍在评估想法的公
司，他们的架构师可能对这些技术在体系中的适用性感兴趣。因此优先选择价值最高的部
分，便能明确演进式架构的长远价值。第三，如果架构师怀疑这些方法的适用性，那么用
系统中最有价值的部分来审查这些概念，能够为是否继续提供了可行的数据。
8.5.3 测试
对演进式架构的增量变更而言，测试是关键的组件，并且适应度函数也在积极地利用测
试。
8.5.4 基础设施
对那些基础设施功能失调的公司来说，构建演进式架构之前可能需要先解决这些问题。
1运维工作外包给别的公司，因此无法控制其体系的关键部分。
2开发和运维之间无法穿透的防火墙
3架构师和开发人员都忽视好的实践
8.6 演进式架构的未来
几个前景方向
8.6.1 基于AI的适应度函数
8.6.2 生成式测试
8.7 为什么（不） 呢
8.7.1 公司为何决定构建演进式架构
每个公司都必须具备软件开发和交付能力
1. 可预测性与可演进性
软件开发领域易变的本质将所有组织推向增量变更。
2. 规模
3. 高级业务能力
在面对不可避免又
无法预测的变化时，演进性架构能赋予公司更好的技术响应能力。
4. 以生产周期为业务指标
生产周期已经成为了一种业务差异。一些大型传统组织将软件视为开
销，并缩减其支出。创新型公司则将软件视为竞争优势。
5. 在量子级别隔离架构特征
过在架构量子级别隔离技术架构，架构师可以专注于单个量子的主要特征，
而无须权衡竞争优先级。
8.7.3 企业为何选择不构建演进式架构
1. 大泥团无法演进
2. 其他架构特征占主导地位
3. 牺牲架构
4. 计划即将停止业务
8.8 商业案例
8.8.1 未来已来……
拥有现代软件架构的公司可能颠覆性地
进入现有的业务领域，并快速占领市场，因为他们的信息技术更先进。
8.8.2 没有后顾之忧地快速前行
如果开发人员构建允许增量变更、比旧架构更强大的架构，将会带来
业务和工程上的双赢
8.8.3 风险更低
8.8.4 新能力
8.9 构建演进式架构
由于架构团队和组件使用团队缺少连接，因此架构团队很难设计出一个有口皆碑，受使用者欢迎的组件。
我们之前都是这么做的，在这种架构模式中，我们有一个巨型数据库，所有的数据都囊括其中。围绕着这个数据库的周围，有一圈各种各样的应用，它们支配着这些数据。
首当其冲的是它让组织者知道并不是所有的东西都必须是模块化的。与此同时，它也激发了大家开始思考，将多种功能更好的集成到一起，而不是紧耦合到一块，比如你可以想想使用中间件，消息队列或者其他一些更松耦合的方法。
SOA也犯了一些错误。最主要的一个问题是其庞大的服务。
其次，SOA倾向于提供方驱动的服务，我指的意思是，当你开始想我要写一个用户服务，我要给用户提供这些信息，因为我是这些信息的提供方。我假设我知道用户将会如何使用这些信息。这种思路其实和设计可重用组件的架构师差不多，我们统称为信息提供方驱动。
SOA的另外一个问题是其充斥着大量的编配（orchestration）,注意这里我们说的是编配而不是编排（choreography）。在管弦乐（也是orchestration这个词）中，有一个统一的指挥，由他来指挥整个乐团，他来设置节奏，音量等各种信息。整个乐团里的个体都无一例外的听命于这个指挥。我们设想一下，如果某个时候同时发生两件事，那么可能就需要两个指挥。总而言之，在这种模型里面，有一个类似指挥的角色来对整个系统全盘负责。而编排却不是这样，在编排的时候，每个个体只需要关注自己周围的其他成员就行，而并没有一个统一的总指挥。当出现问题的时候，每个个体只要知道自己应该怎么调整就行，同样也不需要一个所谓的总指挥来指挥它进行调整。
SOA这种类似管弦乐团的组织方式，过分集中化了，从而导致其本身通常难以测试。
SOA还有一个问题是工艺受阻。SOA需要我们有这样的供应商，能满足业务部门的所有想法，然后业务部门只需要坐在自己的办公室里面做一些自定义的配置就可以了。
微服务（micro-services）
以将微服务理解成正确的SOA模式。我们的关注点还是服务，在微服务的架构里面，服务是作为一个基础单元存在的。SOA本身即是面向服务的架构，所以我们这个其实也可以叫SOA2，但是我们还是用了微服务这个名字，目的就是提醒大家不要搞海量服务。这是一段James Lewis和Martin Fowler的文章中摘抄的一段关于微服务的定义：
微服务有些什么特点呢？
第一个显而易见的特点是，微服务中每个个体服务单元很小。
微服务的另外一个特点是，这些服务是按照业务能力构建的。
微服务中的服务个体都是可以单独部署的。也就是说，只要没有动接口协议，在修改某一个服务个体的时候，完全不用理会其他服务个体。
首先粒度的问题是至关重要的，当你在思考微服务的边界问题时，这应该是使用微服务架构需要做出的一个最重要的决定。
微服务中的各个服务个体是可以独立扩展的，也就是说如果某个服务上的需求量猛增，我们只需要扩展该服务即可，于其他服务无关。
在微服务中，我们还需要考虑服务挂掉的情况，而这些情况在传统单块架构里面一般不用怎么考虑。比如我们有一块业务需要依赖数个独立的微服务，那么我们需要考虑的失败场景就相当多了，
在微服务架构中，因为我们有很多独立的单元，它们需要独自进行部署，因此我们真心离不开基础设施的自动构建，自动化部署和持续交付这些基础。
首先，想清楚边界上下文。这其实是从领域驱动设计一书中拿过来的概念。所谓的边界，指的是你可以将某些部分用一个圈圈起来，圈里的内容代表了一定的业务面。这个所谓的边界其实就是我们设计服务边界时的一个重要指示。再回到我之前说的那个问题，你需要对你的系统有一个全面透彻的认知之后，才能做出这些决定。作为划分服务边界的第一个提示便是：尝试按照领域驱动设计的方式来思考服务的边界应该在哪里。
其次还是这一点：从业务能力的角度来思考服务的边界。想想系统所提供的产品、服务是什么，从这个角度想想怎么样才算一个合理的服务边界。
想想调用者需要什么。
想想服务之间的通信模式。
想想数据结构。
想想联动变化模式。
那么微服务与演进式架构还有什么联系呢？
主要是想用它来快速应对频繁的需求变更，因此微服务所承载的期望便是让我们能尽可能快的适应变化。而演进式架构中所倡导的进化性与此不谋而合。
遵从康威法则。我们需要关注怎么组织团队结构，以及不同的团队结构可能影响到最终的系统形态。只有团队对服务有很好的所有权意识，团队做出来的微服务才是这种松耦合的独立服务
适当耦合。
协议。在微服务架构中，各个服务可以独立演进。那么必不可少的一环就是相互之间的接口协议。
不管是从代码层面还是系统层面，关注测试始终会让你的架构更加完善
微服务相比于传统架构，增加了大量的运维负担。有更多的东西需要部署，有更多的地方需要监控，出错的地方自然也成倍增加，有更多的数据库，对应的需要更多的备份。