微服务学习（二）

前面一篇文章对什么是微服务、服务拆分、服务间通讯、服务部署进行了介绍。接下来继续总结一下微服务的学习。

测试

说到测试，有一个绕不开的话题：怎样做到尽早交付软件和保持软件高质量的平衡。很多时候鱼和熊掌是不可兼得的。
我们可以将测试分为三类：验收测试、功能测试、性能测试。验收测试其实可以算功能测试的一部分，只不过是面向的人群不同。这里主要讲讲功能和性能测试。

• 功能测试（自动化测试）
  自动化测试也可以分为三类：单元测试、服务测试（接口测试）、端到端测试（模拟用户点击）。这三种测试的覆盖范围依次增大，测试的复杂度也依次增加。所以权衡好三种测试的比例就比较重要，书中建议三种测试的量按数量级递减。
• 性能测试
  性能测试围绕的话题就是响应时间、可扩展性、应用安全等等。

监控

• 我们可以将监控分为三类
  • 主机本身监控：比如CPU、内存、硬盘等
  • 服务器的监控：比如登录日志、命令日志等
  • 应用程序的监控：Web 服务监控、缓存、DB监控等
• 日志收集、分析系统：ELK、EFK
• 服务的指标

我们怎样确定服务是否健康哪？数值达到多少应该报警哪？有些数据是常识化的比如CPU、内存使用率；但有些数据就需要通过分析日志进行分析、总结，比如QPS。

• 标准化

监控领域的标准化是至关重要的，不仅是在单个服务，而应是在整个系统。比如标准格式的方式记录日志。

安全

网络安全是一个永远都不可忽视的话题。那在微服务架构中时，安全方面应该考虑哪些问题哪？

• 身份验证和授权
• 服务间的身份认证和授权
• 静态资源的安全

记得加密。不过现在多数都是用第三方的CDN服务。

• 深度防御

防火墙、日志（敏感信息剔除）、网络隔离（比如服务间内网调用）

• 人的因素

人永远都是不可靠的

• 黄金法则

不要自己实现算法

系统设计

• 康威定律

任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致

• 沟通很重要

在系统的设计与实现的方面，团队内要进行频繁的、细颗粒度的沟通

• 服务所有权

拥有服务的团队负责对该服务进行更改。只要更改不破坏服务的消费者，团队就可以随时重新组织代码

• 共享服务

有些服务难以分割、特性团队（敏捷开发）、避免交付瓶颈
微服务会根据业务领域，而不是技术进行建模（important）

• 限界上下文和团队结构

和以限界上下文来定义服务的边界一样，团队也应该和限界上下保持一致

• 团队的人员

和团队的员工清楚地阐明，在微服务的世界里每个人的职责，以及为何这些责任如此重要

规范化微服务

• 故障无处不在

  事情可能会出错，硬盘可能会损坏，软件可能会崩溃，网络也是不可靠的。简单的讲，你的服务越多，发生的概率就越大。从统计学上来说，规范化后故障将成为必然事件。既然故障必然会发生，那我们不如拥抱变化，在阻止不可避免的故障的事情上少花点时间，花更多的时间去优雅的处理它。比如谷歌的裸主板和尼龙扣。

• 跨服务的功能需求

  • 响应时间/延迟
  • 可用性
  • 数据持久性

• 健壮的服务

  • 功能的降级
  • 超时处理
  • 服务熔断

• 幂等

  通常对于接口和队列要做幂等处理

• 扩展

  • 性能更好的主机
  • 拆分负载
  • 分散风险
  • 负载均衡
  • 重新设计

• 扩展数据库

  • 主从
  • TiFB

• 缓存

  • 客户端缓存
  • 服务端缓存（缓存雪崩、缓存击穿）

• 自动伸缩

  服务的自动扩容、自动缩容

• CAP 定理

  一致性、可用性、分区容忍性

• 服务发现、动态服务注册

  • Zookeeper
  • Consul

• 文档服务

  • swagger
  • yapi

总结

• 微服务原则

  • 围绕业务概念建模
  • 接受自动化文化
  • 隐藏内部实现细节
  • 让一切去中心化
  • 可独立部署
  • 服务可降级（隔离）
  • 高度可观察（监控）

• 什么时候不需要微服务

当你不熟悉业务时，最好先不要拆分。可以先构建单块系统，等稳定、熟悉后再拆分。