微服务读书笔记

一、 各种坑
1）微服务拆分过细，too small；
2）微服务基础设施不健全，无法自动化支撑；
3）微服务并不轻量级，规模变大导致甚至比ESB还要复杂。

二、 服务粒度
1）已有团队规模拆分：
根据两个披萨理论衍生出 -> 一个微服务三个人负责开发。
2）3人小组优势：
每个人全面理解整个系统的复杂度；
3人可以形成稳定的人员备份；
3人能够形成有效的讨论，类似单数选举机制，一定会达到半数以上方案通过率；
3人适合用在微服务设计和开发阶段，经过时间发展稳定后，维护就不需要这么多人了。

三、 系统拆分方法
1）基于业务逻辑拆分：
常见拆分方式，将系统中的业务模块按照职责范围拆分出来，每个单独的业务模块拆分成独立的服务；
根据团队人员职称人数，确定拆分微服务个数，例如10人团队拆分4个服务，100人团队拆分40个服务；
如上所述，如果拆分4服务：登录，注册，用户管理等都划到“用户服务”微服务中去；
如果拆分40服务，那么登录，注册，用户信息管理都是一个单独的微服务。
2）基于可扩展拆分：
业务模块按照稳定性排序，把稳定性强的模块（可以甚至毫无关联）可以放到一个系统里，变成一个粗粒度的微服务；
经常变化和迭代的服务拆分为变动服务，保证细粒度，防止快速迭代影响已有成熟稳定功能。
3）基于可靠性拆分：
按照业务模块->核心服务和非核心服务区分，优先保障核心服务高可用；
这样拆分的好处是：避免非核心服务故障影响核心业务，例如日志上报系统；
核心服务的高可用方案也可更简单，存储数据更少，使用组件减少；
核心服务拆分出之后占用资源比不拆分节省很多，节约成本。
4）基于性能拆分：
与可靠性类似，性能要求高的模块拆分出来，提供更多资源（双十一电商入口的排队功能是性能最大的，单独建立一个服务）;

以上四种方式可以组合，不为互斥。

四、 基础设施
1）微服务三个特性需要关注：small，lightweight，automated；
2）服务粒度不合理，必然导致后续继续拆分或整合，如果基础设施不健全，那么工期实现遥遥无期；
3）微服务并不是什么简单又轻量，而是将ESB的功能都转移到分布的基础设施中，互相又使用RESTful API互相调用，并不比SOA轻松；
4）基础设施涵盖：自动化测试，自动化部署，配置中心，接口框架，API网关，服务发现，服务路由，服务容错，服务监控，服务跟踪，服务安全等。

五、 基础设施详解：

1）自动化测试/部署：偏向于DevOps中的CI/CD，全部流程可以遵循DevOps理念具象化的处理流程，
从code upload -> SVN/gitlab -> 自动拉取打包构建（maven等）分发（Jenkins）-> 触发k8s拉取镜像并生成pods提供对外服务；

2）配置中心：统一的微服务CMDB，管理所有微服务实例的配置，k8s读取配置创建自主式pods；

3）接口框架：一般采用HTTP/REST或RPC统一接口协议，并且统一数据传输格式：JSON（xml，yaml都可以转换为json），
接口框架不是可运行系统，一般是以库和包的形式提供给所有微服务调用；

4）API网关：微服务众多如果点对点访问，工作量大且无用，所以需要统一的API网管负责外部系统访问操作，
API网关是外部系统访问的接口，具备接入鉴权，权限控制，传输加密，请求路由，流量控制等功能；

5）服务发现：节点变化能够及时同步到所有其他依赖的微服务，手工是不可能的，两种实现方式：自理式和代理式，
自理式：实现简单，功能通过统一的库和包提供各微服务调用，新实例将访问压力给其他实例，实现注册和加入；
代理式：清晰，负载均衡节点提供服务发现，承担所有新节点访问压力，将新节点加入后端；
服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，例如k8s的etcd；

6）服务路由：一般都是和服务发现设计到一起，新微服务实例通过路由算法加入实例集群，随机，轮询，最小压力，最小连接等；

7）服务容错：一拆多，必然会存在故障扩散，微服务必须自动应付这种场景；
请求重试：第一次失败，重新发起请求再次确认；
流控：某一个微服务请求数量暴增，流量拒绝一部分，保证大部分流量正常请求；
服务隔离：微服务都是集群部署，某个节点故障时，直接隔离下线此节点，避免故障扩散；
主动隔离和被动隔离都是系统自己判断，时效性好，实现起来复杂；
手动隔离及时一般，但是实现简单，
8）服务监控：微服务后节点数量暴增，一旦故障无法快速定位；
解决方案：实时信息搜集并分析；服务监控实时预警；
服务监控需要搜集并分析大量数据，需要做成独立系统，不要集成在服务发现和API网关中；

9）服务跟踪：服务监控的微观世界，拿到的是每个服务的完整请求链信息，即调用链；
通过调用链来跟踪，或者排查问题，或者检测某一个服务的详细信息；

10）服务安全：可以集成到配置中心进行管理，策略封装成通用库给各微服务调用。