微服务

发表于 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
tcp window
慢启动cwnd
<!--more-->
如何学习一个东西
    特点
    为什么
    如何实现
    优缺点
技术能力
业务能力
通用能力(沟通能力，表达能力，学习能力)
提高业绩产出
三层架构
    三层架构是一种分层式软件架构设计理念，通常意义上将程序划分为:表现层、业务逻辑层、数据持久化层
项目流程: 评审->设计->开发->测试->部署
架构的重要性
    对于程序需求我们可以分为应用功能性需求和非功能性需求。架构的重要习惯在于它影响了应用的非功能性需求，也成为质量属性，最显著的就是软件的可维护性、可测试性、可部署性和可扩展性
    架构设计的核心是决策，你需要决策到底是单体架构还是微服务架构更适合你的应用程序，当进行这些决策时，会存在大量的权衡和取舍
单体应用(参考5页图1-2)
    优点
        易于程序大犯规更改
        运维成本低
    缺点
        复杂度过高，很少有人能全面能掌握每个功能模块
        交付周期长且都容易出问题，每次都需要对所有逻辑做全面测试(通常很难做到)
        无法独立部署，某台机器都必须包含完整程序模块
        可扩展性差，要求扩展资源满足所有模块的需求
        可能导致被动长期依赖某个过时的技术栈
程序设计思想
    高内聚，低耦合
微服务(参考10页图1-7)
    基本概念
        AKF扩展立方体
            X轴扩展(水平复制)
            Y轴扩展(根据功能拆分，服务本质上是一个五脏俱全的应用程序，必要时可以借助X或Y轴方式进行扩展)
            Z轴扩展(数据分区，通过类似客户ID这样的请求属性路由请求，将相似的数据分区进行扩展，每个实例负责数据的一部分子集)
        与模块化的关系
            模块化是开发大型复杂应用的基础，面向的是单体应用，然而随着时间推移及反复迭代，单体应用会蜕变为一个大泥球
            微服务架构使用服务作为模块化的单元。服务API为它字舍内构件一个无法逾越的边界，你无法越过API去访问服务内部的类，算是模块化的另一种体现
        与SOA的关系
            SOA通常面向较大的单体应用，服务间通信使用智能管道(例如ESB)，往往采用重量级协议，数据管理采用全局数据模型并共享数据库
            微服务通常面向较小的服务，使用哑管道(例如消息代理、服务间点对点通信，使用REST或gRPC等轻量级协议)，每个服务都有自己的数据模型和数据库
    基本特点
        松耦合
            每个服务之间都是松耦合的，他们仅通过API进行通信，实现这种松耦合的方式之一，是每个服务都拥有自己的私有数据库
        每个服务都可以独立开发、测试、部署、扩展
    优缺点
        优点
            每个服务复杂度相对较低易维护
            服务可独立测试，有更好的容错性
            服务可独立部署，可以快速迭代
            服务可独立扩展
            微服务架构可以实现团队自治
            更容易试验和采纳新的技术
        弊端
            服务拆分定义是一项挑战
            分布式系统带来各种复杂性，使得开发、测试部署变得更困难
            当部署跨多服务功能时需要协调更多团队
    模式
        对于软件开发者来说，需要客服情绪化的本能，找到一种程序设计的方法，这个方法便是采用模式。
        模式是针对特定上下文中发生问题的可重用解决方案，我们把解决类似问题的模式组成一组模式。关系相关的模式集合形成所谓的模式语言，模式语言中的模式共同决定特定领域中的问题
        微服务架构模式语言(24页)
            服务拆分相关模式
                根据业务能力拆分
                根据子域拆分(DDD)
            通信相关模式
                通过微服务架构构建的应用程序是分布式系统，因此进程间通信(IPC)是微服务架构的重要组成部分，架构师需要就服务间与外部世界进行通信做出各种架构和设计决策，分为以下5组
                    通信风格: 使用哪一类进程间通信机制
                    服务发现: 客户端如何获取服务具体实例的IP地址
                    可靠性:服务不可用情况下，如何确保服务间可靠通信
                    事务性消息: 如何将消息发送、事件发布这样的动作与更新业务数据的数据库事务集成
                    外部API: 应用程序的客户端如何与服务进行通信
            实现事务管理的数据一致性相关模式
            在微服务架构中查询数据的相关模式
                服务和数据一一对应会带来一个挑战:有些服务需要从多个服务的数据源获取数据(传统采用SQL JOIN方式完成)，服务数据仅可以通过API方式访问，所以我们不能直接针对服务数据库执行分布式查询，多数情况下我们需要使用命令查询职责隔离(CQRS)的方式来维护一些重要和常用的查询数据视图
            服务部署的相关模式
                serverless
                容器、虚拟机
            可观测性的相关模式
                以下模式可用来设计具备可观测性的服务
                    健康检查API:可返回服务健康状态的api
                    日志聚合: 将服务产生的日志写入一个集中式日志服务器，这个服务器可以提供日志搜索，也可以根据日志情况触发报警
                    分布式追踪: 为每个外部请求分配一个唯一的ID，用于在各个服务间追踪外部请求
                    异常追踪: 把程序异常发送到异常跟踪服务，这个服务会排除重复异常，给开发者发送警告并跟踪每一个异常的解决
                    应用指标: 供维护使用的指标，例如计数器等，导出到指标服务器
                    审计日志: 记录用户的行为
            实现服务自动化测试的相关模式
                消费端驱动的契约测试: 验证服务满足客户端所期望的功能
                消费端契约测试: 验证服务的客户端可以正常与服务通信
                服务组件测试: 在隔离的环境中测试服务
            解决基础设施和边界问题的相关模式
                在微服务架构中，每个服务都必须实现许多与基础设施相关的功能，包括可观测性模式和服务发现模式，还必须实现外部化配置模式，该模式在运行时向服务提供数据库凭据等配置参数。在开发新服务时，更好的方式是在处理这些问题时应用微服务基底模式，这样在现有成熟的基底框架上构建服务
            安全相关的模式
                在微服务架构中，用户身份验证的工作通常由API Gateway完成，然后它必须将有关用户的信息传递给它调用的服务。常见的解决方案是应用访问令牌模式(例如JWT)
    微服务之上:流程和组织
        除了拥有正确的架构外，成功的软件开发还需要在架构、流程和组织方面做一些工作(p30,图1-16)
        进行软件开发和交付的组织
            应用程序的架构往往反映了开发它的组织的结构，因此，反向应用康威定律并设计你的企业组织，使其结构与微服务的架构一一对应，可以确保你的开发团队与服务一样松耦合
        进行软件开发和交付的流程
            微服务架构中需要积极实践持续交付和持续部署
            持续交付的一个关键特征是软件总是随时可以交付，它依赖高水平的自动化，包括自动化测试
    分布式数据管理的架构模式
    针对微服务架构程序的有效测试逻辑
    微服务架构程序的部署方式
    将单个应用重构为微服务架构的策略
开发
测试
部署
可扩展性
技术栈