第二章 演化式架构师
2.1不准确的比较
架构师的一些：
- 确保团队有共同的技术愿景，帮助我们向客户交付他们想要的系统
- 架构师有时只和一个团队一起工作->技术引领者，有时协调多个团队之间，甚至是组织内的工作。
- 非常出色的开发人员才能成为架构师，这个角色也比其他角色更容易招致批评
- 架构师对多个方面会有非常直接的影响：构建系统的质量，同事的工作条件，组织应对变化的能力等
个人理解：架构师是为程序员服务的，创造良好的编码条件与研发流程，对团队演化出最佳实践负责。
架构师很难做好：
- 我们的行业还很年轻，从计算机出现到现在也就70年左右的时间，社会很难理解我们，我们也不清楚自己到底处于什么位置（“架构师是做什么的？解释给自己，解释给别人”）
- 工程师，建筑师，专业认证含金量高，也非常难。架构师，其实我们队什么是好的知之甚少
- 工程图纸和建筑图纸的精确性是我们无法比拟的，他们应对的是精确问题，而架构师面对的是“变化”问题
- 把架构师和工程师或者建筑师比较时，很有可能会做出错误的决定
2.2架构师的演化视角
架构师从一开始就不是为设计出“完美”，存在几十年不需要变更的“大桥”或者“高楼”而出现的。我们面对的是“渐进式演进和变化”
与架构师更好的类比应该是“城市规划师”，城市规划师更多考虑的是人和公共设置如何从一个区域转移到另一个区域，而不是具体在每个区域中发生的事情。
架构师的职责不是设计出“完美系统”，而是保证该系统适合开发人员在其上工作。
架构师应该像城市规划师那样专注在大方向上，只在很有限的情况下参与到非长具体的细节实现中来。要保证系统不但能够满足当前的需求，还能够应对未来的变化。
2.3分区
作为架构师，不应该过多关注每个区域内发生的事情，而应该关注区域之间的事情（服务的边界）。应该考虑不同的服务之间应该如何交互，或者说保证我们能够对整个系统的健康状态进行监控。如果一个服务决定通过HTTP暴露REST接口，另一个用的是protocol buffers,第三个用的是Java RMI，那么作为一个服务的消费者就需要支持各种形式的交互，这对于消费者来说就是噩梦。
架构师和团队真正坐在一起，这件事情再怎么强调也不过分！如果有多个团队，可以把每周划分出时间来和不同的团队一起工作，了解系统的使用者才能做出好用的系统。
2.4一个原则性的方法
做系统设计方面的决定通常就是在做“取舍”！！！“面试造核弹，进来拧螺丝”，这句话是扯~
2.4.1战略目标
制定公司技术愿景的人，可能需要花费更多的时间和组织内非技术的部分（业务部门）进行交互。好的架构师，沟通能力，业务理解的能力是不可或缺的。
2.4.2原则
为了和更大的目标保持一致，我们会制定一些具体的规则，并称之为原则，它不是一成不变的。
一般来讲，原则最好不要超过10个，或者能过写在一张海报上，不然大家会很难记得住。而且，原则越多，它们发生重叠和冲突的可能性就越大。
原则不用太多，其实就那么几条，而且比较稳定，而具体实践却是在不断变化的，但始终遵循原则。
image.png
image.png
2.4.3实践
实践是用来巩固原则的。
2.4.4将原则和实践相结合
在一个足够小的群组，将原则和实践进行结合是没有问题的。但在一个大型组织中，原则和实践可能不同，比如同一个原则，.Net团队和Java团队各有一套实践。
2.4.5真实世界的样子
实践改动的会比较频繁，而原则基本变化很少。把这样一个图表打印出来共享给相关人员，其中每个条目很简单，开发人员应该很容易记住它们。
image.png
2.5要求的标准
在优化单个服务自治性的同时，也要兼顾全局。一种能够帮助我们实现平衡的方法就是，清楚的定义出一个好服务应有的属性。
2.5.1监控
能够清晰地描绘出跨服务系统的健康状态非常关键。每个服务应该对外不透明，并且不要为了服务的具体实现而改变监控系统。日志功能和监控情况类似：也需要集中式管理。
image.png
2.5.2接口
选用少数几种明确的接口技术有助于新消费者的集成，太多的不同集成技术是不利于集成的。（统一，标准，让各个服务保持足够自治性非透明的同时，交互边界最好采用标准方式）
2.5.3架构安全性
P(分区容忍性)，单个服务或者系统的奔溃不影响全局。让每个服务使用一个断路器，可以熔断，可以降级。
2.6代码治理
让大家如你所愿做好一件事件，最好的办法就是提供范例和服务代码模板。
范例
如果在系统中，人们有比较好的代码范例可以模仿，那么他们也就不会错的很离谱。
你提供的优秀范例应该来自真实的项目，而不是专门实现的一个完美的例子。
裁剪服务代码模板
好处：
- 开发效率高
- 出错不会太离谱
坏处：
- 如果模板升级了，需要修改的地方会很多
- 如果做成共享的依赖库，DRY防止了，但却容易导致系统过度耦合（之前也提到过使用共享库的问题）
关于咱们平台包的问题，提一下~
2.7技术债务
架构师的职责就是从更高的层次触发，理解如何做权衡。（这个很有体会，对于普通开发人员需要的是“最佳实践”，不要各种分析，各种对比，直接拿来就用，爽，快，效率高。但对于架构师来说，要做的事情是看懂各种螺丝钉，熟练使用各种螺丝刀，知道何时何地何种场景适合用何种螺丝刀来拧何种螺丝~）
团队可以维护一个债务列表，并且定期回顾。（咱们的语雀中提到的还未做的事情），我们目前很多事情已经在做，只是大家并不知道或者并不了解，做的这些其实就是最佳实践中的一些内容，比如站立会三件事，比如两周一个冲刺等等。
2.8例外管理
首先，前边也提到，原则很少变，而实践几乎是一直都在变化的。
不同的公司对开发人员自由度的定义是不同的，作者提到“如果所在组织对开发人员有非常多的限制，那么微服务并不适合你！”，这句话其实是值得商榷的，不应该限定太死，但原则时必须有的。
很多时候，书中的内容是前人的思考，总结，实践。对于我们来说，需要知道，了解，然后按照项目中的实际情况来做取舍和改变，现实和书的差距很大，照搬书，即使是对的也会很痛苦。
几张图：
image.png
image.png
2.9集中治理和领导
架构师的部分职责是治理，治理的定义：
治理通过评估干系人的需求，当前情况以及下一步的可能性来确定企业目标的达成，通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。
架构师有确保技术愿景的职责，要确保我们构建的这个系统符合愿景，在必需的时候还应对愿景进行演化。
架构师需要不断了解新的技术，从而做出对比，取舍，演进。
架构师需要和团队坐在一起编码，了解开发人员的痛苦，快乐。
架构师有时会遇到和团队整体决定相左的时候，这个时候需要分析，而不是拍脑袋决定哪一方是对是错。
架构师有时候像老师，教学生骑车的时候，绝对不应该一直扶着他们前行，把他们抛出去，经历该有的经历，然后给予指导。（当然这个分情况。“不可能让你乱来，随便实验线上环境，晚上要上线，现在你还要探索。。。”）
架构师不作为就会成为花瓶，架构师过于强势又会让团队感觉没有一点自主权。
2.10建设团队
对于架构师来说，需要的成长很多。但有一件非常重要的事情就是“帮助团队中的人成长！”
（看一个人是否牛X有两方面，第一看他自己是否牛X；第二，看他带出来的团队是否牛X。所以，我们每个人都有更加优秀的义务，让自己优秀，让团队的每个人因为在这样的团队中自豪）
微服务架构下，每个组员都有机会独自负责一个服务，独自负责一个代码库。让组员在单个服务上经过锻炼之后，可以给予他们更多的责任，从而帮助他们逐步达成自己的职业目标。
伟大的软件来自伟大的人。所以，如果你只担心技术问题，那么恐怕你看到的问题远远不及一半。
