测试

一、测试分类

1、单元测试

        测试方法层面

2、服务测试

        绕开用户界面、直接针对服务的测试

3、端到端的测试

        端到端的测试会覆盖整个系统，需要界面操作。

二、部署后再测试

1、蓝/绿发布

        假如生产环境已经部署了版本V123, 在部署新版本V456时，先将V456部署到生产环境，但是先不接受请求，等对V456测试后没问题，然后再切换生产负荷到新部署的V456。这样如果新版本有任何错误，能够快速恢复到旧版本。

2、金丝雀发布

        金丝雀发布，是指通过将部分生产流量引流到新部署的系统，来验证系统是否按预期执行（功能性的和非功能性的）。如果新版本没有达到预期，可以迅速恢复到旧版本，如果新版本达到预期，可以引导更多的流量到新版本。

        金丝雀发布与蓝/绿发布的不同之处是：新旧版本共存的时间更长，而且经常会调整流量。

 

监控

        微服务的监控：监控小的服务，聚合起来看整体

一、监控手段：

        * 日志：logstash可以解析多种日志文件格式，并将它们发送给下游系统进行进一步调查。还有Kibana甚至可以根据日志生成图表。

        * 语义监控

        * 关联标识

        

二、监控建议

对于每个服务而言：

        * 最低限度要跟踪请求响应时间。做好之后，可以开始跟踪错误率及应用程序级的指标。

        * 最低限度要跟踪所有下游服务的健康状态，包括下游调用的响应时间，最好能够跟踪错误率。一些像Hystrix这样的库，可以在这方面提供帮助。

        * 标准化如何收集指标以及存储指标。

        * 如果可能的话，以标准的格式将日志记录到一个标准的位置。

        * 监控底层操作系统，这样就可以跟踪流氓进程和进行容量规划。

对系统而言：

        * 聚合CPU之类的主机层级的指标及应用程序级指标。

        * 确保你选用的指标存储工具可以在系统和服务级别做聚合，同时也允许你查看单台主机的情况。

        * 确保指标存储工具允许你维护数据足够长的时间，以了解你的系统的趋势。

        * 使用单个可查询工具来对日志进行聚合和存储。

        * 强烈考虑标准化关联标识的使用。

        * 连接什么样的情况需要行动，并根据这些信息构造相应的警报和仪表盘。

        * 调查队各种指标聚合方式做统一化的可能性，可以使用类似Suro、Riemann这样的工具。

 

安全

一、身份认证和授权

        身份认证，是确认他是谁的过程，对于一个人，通常通过用户输入的用户名和密码来验证，或通过指纹来确认操作者“他”是主体本人。

        授权，可以把主体映射到他可以进行的操作中，通常一个主体通过了身份验证之后，系统根据主体的身份信息授权其可以进行的操作。

二、单点登录

        单点登录时身份认证和授权的一种常用解决方案。当一个主体试图访问一个资源时，他会被重定向到一个身份提供者哪里进行身份验证，一旦身份提供者确认主体已通过身份验证，它会发消息给服务提供者，让服务提供者决定是否允许他访问资源。

        通过单点登录网关的方式，可以避免每个服务实现重定向到身份提供者。

        通过登录网关提供粗粒度的身份验证，如果能同时获取主图的属性，则可以据此做出更细致的授权。

三、服务间的身份验证和授权

        当主体是服务时，如何验证主体的身份和进行授权？

        * 可以选择，在边界内允许一切，如果数据不敏感，这种方式可能没问题，但这种模型存在一定的风险；

        * 使用HTTPS基本身份验证，服务器需要管理自己的SSL证书（或自行签发证书）；

        * 使用SAML或OpenID connect来作为身份验证和授权方案，可以在服务之间的交互中也使用它们。

        * 使用客户端证书（TLS,安全传输层协议），每个客户端安装一个证书，服务器验证客户端证书的真实性。

        * 在HTTP之上使用HMAC(基于哈希的消息码)对请求进行签名。

        * 使用API密钥。

四、静态数据的安全

        * 使用众所周知的加密算法；（因为它经过了同行评审）；

        * 密钥单独管理，（将密钥和加密的数据放在一起不一定可靠，常用的解决方案是，使用单独的安全设备来加密和解密数据，或者使用单独的密钥库，当服务需要密钥时访问它）；

        * 按需加密，第一次看到数据的时候就对它加密，只在需要的时候解密，并确保解密后的数据不会存储在任何地方。

        * 重要的数据需要备份，确保备份的数据也是加密的。

五、深度防御

        * 使用一个或多个防火墙，确保主机的安全。

        * 好的日志实践应该聚合多个系统的日志，虽然不能预防入侵，但可以帮助检测是否被入侵，以便后续恢复。另外，日志中不应该保存敏感信息，如果泄露可能会成为攻击者的重要目标；

        * 使用入侵检测（和预防）系统，监控网络和主机，方发现可疑行为时报告；

        * 使用网络隔离，把微服务放进不同的网段，以进一步控制服务间的通信，例如AWS提供自动创建VPC(虚拟私有云)的能力，它允许主机处在不同的子网中，然后通过定义对等互连规则，控制VPC之间的访问；

        * 操作系统层面控制，给操作系统的用户尽量少的权限（这样即使被盗，造成的伤害也最小），定期给操作系统安装补丁。

 

康威定律和系统设计

        梅尔.康威曾发表论文指出：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

埃里克.S.雷蒙德的比喻：如果你有四个小组开发一个编译器，那你会得到一个四步编译器。

一、组织的分类

        创建系统的组织可以分为两大类：松耦合组织和紧耦合组织。

        紧耦合组织的一个例子是商业产品公司，他们所有的员工都在一起工作，并有着一致的愿景和目标；松耦合组织的典型代表是分布式开源社区。

        组织的耦合度越低，其创建的系统的模块化就越好，耦合也越低；组织的耦合度越高，其创建的系统的模块化也越差。

二、面对组织结构与系统性质和质量的影响关系，我们该怎么做

（1）、系统设计适应沟通途径

        单独的团队负责系统设计和实现的各个方面，团队内可以进行频繁的、细粒度的沟通，这个有着细粒度沟通能力的团队能够与服务内部频繁讨论代码这个需求很好的匹配；

        异地团队如果维护一个服务，由于地域和时区的界限，使得团队之间非常难于进行细粒度的沟通。只能依靠粗粒度的沟通，这样沟通成本较高，协调变化的成本也就比较高。异地团队之间粗粒度沟通形成的粗粒度API,可以考虑作为服务拆分的边界。

（2）、实现服务的团队自治

        将服务的方方面面，从应用程序的需求、构建、部署到运维。把决定权交给服务所属的团队本身，赋予团队更多的权利和自治，也使其对工作更负责。

三、面对共享服务，该怎么做

（1）、共享服务的原因

        * 因为服务的拆分成本太高，或者组织未发现需要拆分；

        * 特性团队，是对一些IT组织中，团队结构围绕技术边界进行组织的一种修正，例如，组织内有团队专门负责界面，另一个团队负责程序逻辑，第三个团队负责数据库，而特性团队则会跨越所有层提供完整的功能，当组织内大范围采用特性团队后，所有的服务都是共享的。（正确地思路：微服务领域，服务会根据业务领域，而不是技术进行建模）

        * 有时共享服务是为了解决交付瓶颈问题。（因为，某个服务修改大量修改，需要其他服务进行修改，为了提交交付效率才这么做，更好的解决方法是，派团队内的人去其他团队内部帮助协调开发，或者优化服务之间的关系，减少联动修改依赖）。

（2）、解决共享服务的办法

        * 组织内部开源，并设置服务守护者角色

        在组织内部将服务开源，任何其他团队的成员都可以提交修改，但同时设置服务的守护者，这些守护者负责服务的质量，审批其他开发者提交的修改。注：这种模式类似标准开源项目的模式，分离受信任的提交者（核心团队）和不受信任的提交者（团队外提交变更的人）；另外服务越不成熟就越难让核心团队之外的人提交更改，所以通常需要确保核心团队之外的人可以修改之前，服务已经相当成熟，需要的改动很少。

四、限界上下文和团队结构

        我们以限界上下文来定义服务边界，因此也希望团队也与限界上下文保持一致，这样有很多好处，首先，团队会发现它在限界上下文内更容易掌握领域的概念，其次，限界上下文中的服务更有可能发生交互，保持一致可以简化系统设计和发布的协调工作。

        注：反向的康威定律

        康威定律谈论了组织如何影响系统设计，那么反过来讲，系统设计能改变组织吗？会的，组织结构通常也不会早于系统设计，反而会根据系统设计发展（本质是业务发展需要），无论系统有什么设计缺陷，我们都不得不通过改变组织结构来推动系统的更改。

 

规模化微服务