读书笔记: 微服务设计
https://book.douban.com/people/fleure/annotation/26772677/
单点登录网关
<原文开始>这种方法的最后一个问题是，它会给你一种虚假的安全感。我喜欢深度防御的理念，从网络边界，到子网，到防火墙，到主机，到操作系统，再到底层硬件。</原文结束>
<原文开始>网关层承担越来越多的功能后，最终本身会是一个庞大的耦合点。</原文结束>
<原文开始>网关可以提供相当有效的粗粒度的身份验证。例如，它可以阻止任何未登录用户访问帮助台应用程序。</原文结束>
<原文开始>你应该倾向于使用粗粒度的角色，围绕组织的工作方式建模。</原文结束>
## consul
<原文开始>consul 底层的 serf 可以处理集群中的节点检测、故障管理和报警。然后 consul 在其之上添加了服务发现和配置管理。</原文结束>
## 特性团队
<原文开始>特性团队（基于特性开发的团队）的想法，是一个小团队负责开发一系列特性需要的所有功能，即使这些功能需要跨组件（甚至服务）的边界。</原文结束>
<原文开始>许多情况下，特性团队是对传统的 IT 组织中，团队结构围绕技术边界进行组织的一种修正。例如，你可能有一个团队专门负责用户界面，另一个团队负责应用程序逻辑，第三个团队负责处理数据库。这种环境下，特性团队迈出了一大步，它跨越所有层提供完整的功能。</原文结束>
<原文开始>大范围地采用特性团队后，所有服务都是共享的。</原文结束>
## 客户端库
<原文开始>如果开发服务端 API 和客户端 API 的是同一批人，那么服务端的操作逻辑就有可能泄露到客户端中。.. 潜入到客户端的逻辑越多，内聚性就越差，然后你必须在修复一个服务端问题的同时，也需要对多个客户端进行修改。</原文结束>
## 技术边界
<原文开始>这个组织逐渐决定对团队进行扩容，增加了一个巴西团队来分担一部分工作。系统被划分成两部分，一部分面向前端，该部分不保存任何状态，如图 3-4 所示；后端部分就是一个简单的数据存储，通过 RPC 提供服务。基本上你可以理解为，把一个代码库中的仓储层变成了一个独立的服务。
后来发现，需要频繁地同时修改两个服务。两个服务都是偏底层的、RPC 风格的方法调用，而这是非常不稳定的。这个服务接口也很繁琐，会导致性能问题。这就导致了对 RPC 批处理的需求。我把这种架构称为洋葱架构，因为它又很多层，而且当纵切这些层次时，我只想哭。</原文结束>
## 建设团队
<原文开始>帮助别人成长的形式有很多种，其中大部分都超出了本书的范围。微服务架构本身能够提供一种很好的形式。在单块系统中，人们对某些事情负责的机会非常有限，而在微服务架构中存在多个自治的代码库，每个代码库都有自己独立的生命周期，这就给更多人提供了对单个服务负责的机会，而当这些人在单个服务上得到足够锻炼之后，就可以给他们更多的责任，从而帮助他们逐步达成自己的职业目标，同时通过分担职责也可以防止某一个人的负担过重。</原文结束>
<原文开始>我坚定地相信，伟大的软件来自于伟大的人。所以如果你只担心技术问题，那么恐怕你看到的问题远远不及一半。</原文结束>
## 集中治理和领导
<原文开始>架构师的部分职责是治理。那么治理又是什么意思呢？COBIT （Control Objectives for Information and Related Technology）给出了一个很好的定义：治理通过评估干系人的需求、当前情况以及进一步的可能性来确保企业目标的达成，通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。</原文结束>
<原文开始>架构师会对很多事情负责。他们需要确保有一组可以指导开发的原则，并且这些原则要与组织的战略相符。他们还需要确保，以这些原则为指导衍生出来的实践不会给开发人员带来痛苦。他们需要了解新技术，需要知道在什么时候做怎样的取舍。上述这些职责已经相当多了，但是他们还需要让同事也理解和决定这些取舍，并执行下去。对了，还有前面提到的：他们需要花时间和团队一起工作，甚至是编码，从而了解所做的决定对团队造成了怎样的影响。</原文结束>
<原文开始>你没法替代他们去骑车。你会看着他们摇摇晃晃地前进，但是如果每次你看到他们要跌倒就上去扶一把，他们永远都学不会。而且无论如何，他们真正跌倒的次数会比你想象的少。但是，如果他们马上就要驶入车流繁忙的大马路，或者附近的鸭子池塘，你就必须站出来了。类似地，作为一名架构师，你必须要在团队驶向类似鸭子池塘这样的地方时抓紧他们。</原文结束>
<原文开始>还有一点要注意的是，即使你很清楚什么是对的，然后尝试去控制团队，也可能会破坏和团队的关系，并且会使团队感觉他们没有话语权。有时候按照一个你不同意的决定走下去反而是正确的，知道什么时候可以这么做，什么时候不要这么做是很困难的，但有时也很关键。</原文结束>
## 代码治理
<原文开始>聚在一起，就如何做事情达成共识是一个好主意。但是，花时间保证人们按照这个共识来做事情就没那么有趣了，因为在各个服务中使用这些标准做法会成为开发人员的负担。我坚信应该使用简单的方式把事情做对。我见过比较奏效的两种方式是，提供范例和服务代码模板。</原文结束>
<原文开始>编写文档是有用的，... 但是开发人员更喜欢可以查看和运行的代码。</原文结束>
<原文开始>创建服务代码模板不是某个中心化工具的职责，也不是指导我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践，所以你的团队也需要负责更新这个模板。</原文结束>
<原文开始>我也见过一个团队的士气和生产力是如何被强制使用的框架给毁掉的。基于代码重用的目的，越来越多的功能被加入到一个中心化的框架中，直到把这个框架变成一个不堪重负的怪兽。</原文结束>
<原文开始>你还需要知道，重用代码可能引入的危险。在重用代码的驱动下，我们可能会引入服务之间的耦合。... 一些我接触过的团队，把服务代码模板简单地做成了一个共享的库依赖，这时他们就要非常小心地防止对 DRY 的追求导致系统过度耦合。</原文结束>
## 一个原则性方法
<原文开始>一般来讲，原则最好不要超过 10 个，或者能够写在一张海报上，不然大家很难记住。</原文结束>
<原文开始>实践应该巩固原则。</原文结束>
<原文开始>有些东西对一些人来说是原则，对另一些人来说则可能是实践。比如，你可能会把使用 HTTP/REST 作为原则，而不是实践。这也没什么问题，关键是要有一些重要的原则来指导系统的演化，同时也要有一些细节来指导如何实现这些原则。对于一个足够小的群组，比如单个团队来说，将原则和实践进行结合是没有问题的。但在一个大型组织中，技术和工作实践可能不一样，在不同的地方需要的实践可能也不同。不过这也没关系，只要它们能映射到相同的原则即可。比如一个 .net 团队可能有一套实践，一个 java 团队有另一套实践，但背后的原则是相同的。</原文结束>
## 演化式架构师
<原文开始>在我们的行业中，这种建筑师的视角会导致一些非常糟糕的实践。人们试图通过大量的图标和文档创建出一个完美的方案，而忽视了很多基础性的未知因素。</原文结束>
<原文开始>城市规划师应该尽量去预期可能发生的变化，但是也需要明白一个事实：尝试直接对各个方面进行控制往往不会奏效。</原文结束>
<原文开始>未来的变化很难预见，所以与其对所有变化的可能性进行预测，不如做一个允许变化的计划。为此，应该避免对所有事情做出过于详尽的设计。</原文结束>