forked from HappySnailSunshine/JavaInterview
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Dubbo.md
2584 lines (1372 loc) · 94.3 KB
/
Dubbo.md
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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# Dubbo
# 一.Dubbo
## 单体架构
<img src="../media/pictures/Dubbo.assets/be01386bf19f71fe8467bf20132bcc0c-1611633445449.png" />
<img src="../media/pictures/Dubbo.assets/image-20210126155143106.png" alt="image-20210126155143106" style="zoom: 67%;" />
### 优缺点
<img src="../media/pictures/Dubbo.assets/image-20210126155215310.png" alt="image-20210126155215310" style="zoom: 50%;" />
修改后 测试麻烦
迭代困难
修改工具类，其他的模块都受到影响
某个模块扩展扩容起来麻烦
部署和回滚不方便
## 微服务架构引入
### 概念
微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。
### 架构图
<img src="../media/pictures/Dubbo.assets/image-20210126155240104.png" alt="image-20210126155240104" style="zoom:67%;" />
### 微服务架构设计原则
拆分足够小
服务之间轻量级通信
### 微服务的优点
相对于单体架构，它的主要特点是**组件化、松耦合、自治、去中心化**，体现在以下几个方面：
一组小的服务
服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
独立部署运行和扩展
每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
独立开发和演化
技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
独立团队和自治
团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。
### 微服务的缺点
服务拆分微服务架构可能带来过多的操作。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
分布式事务比较难处理
当服务数量增加，管理复杂性增加。
等
### 微服务拆分思路
#### 横向拆分
根据业务来拆分
<img src="../media/pictures/Dubbo.assets/image-20210126155320253.png" alt="image-20210126155320253" style="zoom:50%;" />
#### 纵向拆分
根据层次来拆分
<img src="../media/pictures/Dubbo.assets/image-20210126155336904.png" alt="image-20210126155336904" style="zoom:50%;" />
### 微服务的选择
下面两个就想当于自配电脑(Dubbo),和品牌电脑的关系(Springcloud)!
#### Dubbo （RPC）
##### Dubbo(这个是传输层协议 速度快)
Dubbo是阿里集团开源的一个极为出名的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。所以目前Dubbo是一种广泛使用的微服务架构框架。
###### RPC
RPC= Remote Process Call 跨进程调用
RPC的本质是提供了一种轻量无感知的跨进程通信的方式，在分布式机器上调用其他方法与本地调用无异（远程调用的过程是透明的，你并不知道这个调用的方法是部署在哪里，通过PRC能够解耦服务）。RPC是根据语言的API来定义的，而不是基于网络的应用来定义的，调用更方便，协议私密更安全、内容更小效率更高。
<img src="../media/pictures/Dubbo.assets/image-20210126155354891.png" alt="image-20210126155354891" style="zoom:50%;" />
客户端（Client），服务的调用方。
服务端（Server），真正的服务提供者。
客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
基于TCP/IP协议。速度快。
<img src="../media/pictures/Dubbo.assets/image-20210126155406702.png" alt="image-20210126155406702" style="zoom:50%;" />
#### Springcloud （HTTP）
##### Springcloud （HTTP/REST）(这个是应用层协议 速度慢 但是全 想当于品牌电脑)
Spring Cloud来源于Spring，利用Spring Boot进行快捷开发。 Spring
Cloud基本上都是使用了现有的开源框架进行的集成，学习的难度和部署的门槛就比较低，对于中小型企业来说，更易于使用和落地。Spring
Cloud
核心组件Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service
Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。
#### http
**应用层协议**，简单。
http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议
进行传输。
使用Http协议的微服务，通常返回json数据，然后把json转换为对象。
#### 小结
RPC服务和HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。**总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估。**
### 微服务的基本概念
#### 服务提供者Provider
提供服务的具体实现。
#### 服务调用者Consumer
通过一些框架来调用服务提供者提供的服务
注意：同一个微服务，既可以是provider，也可以是consumer。
### 拓展 阿里架构演变之路
https://segmentfault.com/a/1190000018626163 这是作者原来文章的链接!
下面是从源出处复制过来的!
#### 1. 概述
本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
#### 2. 基本概念
在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：
- **分布式**
系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上
- **高可用**
系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性
- **集群**
一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性
- **负载均衡**
请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的
- **正向代理和反向代理**
系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
#### 3. 架构演进
##### 3.1 单机架构
以淘宝作为例子。在网站最初时，应用数量与用户数都较少，可以把Tomcat和数据库部署在同一台服务器上。浏览器往www.taobao.com发起请求时，首先经过DNS服务器（域名系统）把域名转换为实际IP地址10.102.4.1，浏览器转而访问该IP对应的Tomcat。
> **随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务**
##### 3.2 第一次演进：Tomcat与数据库分开部署
Tomcat和数据库分别独占服务器资源，显著提高两者各自性能。
> **随着用户数的增长，并发读写数据库成为瓶颈**
##### 3.3 第二次演进：引入本地缓存和分布式缓存
在Tomcat同服务器上或同JVM中增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。其中涉及的技术包括：使用memcached作为本地缓存，使用Redis作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。
> **缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢**
##### 3.4 第三次演进：引入反向代理实现负载均衡
在多台服务器上分别部署Tomcat，使用反向代理软件（Nginx）把请求均匀分发到每个Tomcat中。此处假设Tomcat最多支持100个并发，Nginx最多支持50000个并发，那么理论上Nginx把请求分发到500个Tomcat上，就能抗住50000个并发。其中涉及的技术包括：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，主要支持http协议，还会涉及session共享、文件上传下载的问题。
> **反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈**
##### 3.5 第四次演进：数据库读写分离
把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。其中涉及的技术包括：Mycat，它是数据库中间件，可通过它来组织数据库的分离读写和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。
> **业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能**
##### 3.6 第五次演进：数据库按业务分库
把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本文讨论的重点，有兴趣的可以自行搜索解决方案。
> **随着用户数的增长，单机的写库会逐渐会达到性能瓶颈**
##### 3.7 第六次演进：把大表拆分为小表
比如针对评论数据，可按照商品ID进行hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。
这种做法显著的增加了数据库运维的难度，对DBA的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。
目前开源和商用都已经有不少MPP数据库，开源中比较流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、华为的LibrA等等，不同的MPP数据库的侧重点也不一样，如TiDB更侧重于分布式OLTP场景，Greenplum更侧重于分布式OLAP场景，这些MPP数据库基本都提供了类似Postgresql、Oracle、MySQL那样的SQL标准支持能力，能把一个查询解析为分布式的执行计划分发到每台机器上并行执行，最终由数据库本身汇总数据进行返回，也提供了诸如权限管理、分库分表、事务、数据副本等能力，并且大多能够支持100个节点以上的集群，大大降低了数据库运维的成本，并且使数据库也能够实现水平扩展。
> **数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈**
##### 3.8 第七次演进：使用LVS或F5来使多个Nginx负载均衡
由于瓶颈在Nginx，因此无法通过两层的Nginx来实现多个Nginx的负载均衡。图中的LVS和F5是工作在网络第四层的负载均衡解决方案，其中LVS是软件，运行在操作系统内核态，可对TCP请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于Nginx，可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件，与LVS提供的能力类似，性能比LVS更高，但价格昂贵。由于LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚拟IP重定向到另外一台正常的LVS服务器，从而达到LVS服务器高可用的效果。
此处需要注意的是，上图中从Nginx层到Tomcat层这样画并不代表全部Nginx都转发请求到全部的Tomcat，在实际使用时，可能会是几个Nginx下面接一部分的Tomcat，这些Nginx之间通过keepalived实现高可用，其他的Nginx接另外的Tomcat，这样可接入的Tomcat数量就能成倍的增加。
> **由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同**
##### 3.9 第八次演进：通过DNS轮询实现机房间的负载均衡
在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。
> **随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求**
##### 3.10 第九次演进：引入NoSQL数据库和搜索引擎等技术
当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。
当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。
> **引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难**
##### 3.11 第十次演进：大应用拆分为小应用
按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心Zookeeper来解决。
> **不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级**
3.12 第十一次演进：复用的功能抽离成微服务
如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。
> **不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱**
##### 3.13 第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异
通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。个人理解，微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。
> **业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难**
##### 3.14 第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理
目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。
在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响（在3.14节之前，服务运行在新增机器上需要修改系统配置来适配服务，这会导致机器上其他服务需要的运行环境被破坏）。
> **使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低**
##### 3.15 第十四次演进：以云平台承载系统
系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。
所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：
- **IaaS：**基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
- **PaaS：**平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
- **SaaS：**软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。
> **至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论**
#### 4. 架构设计总结
- **架构的调整是否必须按照上述演变路径进行？**
不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
- **对于将要实施的系统，架构应该设计到什么程度？**
对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
- **服务端架构和大数据架构有什么区别？**
所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。
- **有没有一些架构设计的原则？**
- N+1设计。系统中的每个组件都应做到没有单点故障；
- 回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
- 禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
- 监控设计。在设计阶段就要考虑监控的手段；
- 多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
- 采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
- 资源隔离设计。应避免单一业务占用全部资源；
- 架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
- 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
- 使用商用硬件。商用硬件能有效降低硬件故障的机率；
- 快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
- 无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
## Dubbo引入
### Dubbo介绍
<http://dubbo.apache.org/en-us/>
### Spring和Dubbo的结合
#### 入门案例
参考文档：<https://dubbo.gitbooks.io/dubbo-user-book/content/quick-start.html>
##### 导包
见资料。
##### 服务提供者
##### 代码
首先我们在服务端定义一个接口
然后我在服务端提供这个接口的实现
##### 配置
##### 服务器使用者
###### 代码
远程调用代码
###### 配置
##### 测试结果
**这里需要注意的是,这里服务的提供者和服务的消费者名字要一样,不光是接口和类的名字一样,而且包名也要一样!**
这里的两个接口必须要一样!
### 架构
#### 第一种方式直连!相当于没有上面注册!
#### 第二种方式用注册中心中的zookepper!
zookepper使用,首先减压!
然后进去目录中,将文件名字修改:
因为启动以后会默认找zoo.cfg这个文件!
然后需要启动这的zookeeper,这里需要注意的是,路径不能有中文,目录如果放的太深,或者路径中有其他奇怪字符,这个是运行不了的,会一直报错,提示找不到主类!
这样就启动成功啦!
这其中遇到一个问题,问题详细信息看error18!
zookeeper会受电脑广播和其他东西的影响!
而且在wins环境下,会运行不稳定!有时候需要耐心一定!
出现这个,就意味着成功啦!
#### 入门案例分析
### SpringBoot 和 Dubbo的结合
参考文档<https://github.com/alibaba/dubbo-spring-boot-starter>
首先需要导一个包!springboot对dubbo的支持包!上面是github的地址!
#### 导包
```xml
<dependency>
<groupId>com.alibaba.spring.boot</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>2.0.0</version>
</dependency>
```
Springboot约定大于配置,官方文档中没有配置端口,其实是默认配置了端口,只要不修改端口,默认就是
```xml
spring.application.name=dubbo-spring-boot-starter
spring.dubbo.server=true
spring.dubbo.registry=N/A
```
#### 提供者
**注意:这里的Service是dubbo中的!要注意!**
使用之前要导包!
配置：
```java
spring.application.name=dubbo-spring-boot-starter
spring.dubbo.protocol.name=dubbo
spring.dubbo.protocol.port=20880
spring.dubbo.server=true
spring.dubbo.registry=N/A
```
#### 使用者
也要实现一模一样的接口！
然后在main方法里测试！
**注意**:这里要开启功能,需要上面的注解
```java
@EnableDubboConfiguraion
```
#### 测试
先启动服务提供者：
在启动使用者：
这行log出现在下面的空行位置
在老师上课的dome中,老师使用了一个公共包common,公共包里面的pom.xml配置,要写成
```xml
<packaging>jar</packaging>
```
公共包里面建放了DemoService接口,那么下面两个中就没有必要放这个接口啦!
但是要导入上面的common包!
```xml
<!--要引入common包里面的包,这里需要引入common包-->
<dependency>
<groupId>com.cskaoyan</groupId>
<artifactId>common</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
```
这样,下面两个包就可以使用common里面的包啦!
这种导入一个公共包的做法,不容易犯错!
公共类中导入一个依赖,然后下面两个包中都是可以使用的!
```xml
<!--这个依赖狭下面两个都需要!-->
<dependency>
<groupId>com.alibaba.spring.boot</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>2.0.0</version>
</dependency>
```
这里可以看到下面两个包中已经包含了上面包中的,已经包含了公共包中的依赖!
上面的是直连
如果想让项目变成需要注册的,还需要导入zookeeper
```xml
<!--这个是导入zookeeper的包-->
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
<version>0.10</version>
</dependency>
```
### 直连提供者
#### 介绍
我们刚才使用的微服务的用法，实际上是一种最简单的点对点调用方式。这种方式通常用于测试环境。
在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，A
接口配置点对点，不影响 B 接口从注册中心获取列表。
**注意** 为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。
#### 弊端
不利于分布式的扩展
### 服务注册和服务发现
#### 架构图
这里是长连接!长连接最主要的特点是建立心跳连接!过一会会发射一些数据!
名词解释：
<img src="../media/pictures/Dubbo.assets/image-20210126155505462.png" alt="image-20210126155505462" style="zoom:50%;" />
### ZooKeeper
是一个中间件，负责为分布式系统提供协调服务。服务注册和服务发现。
<https://www.apache.org/dyn/closer.cgi/zookeeper/>
下载路径
下载解压之后
修改一个文件名
zoo_sample.cfg修改为
启动：
<img src="../media/pictures/Dubbo.assets/image-20210126155526427.png" alt="image-20210126155526427" style="zoom: 67%;" />
### Spring +dubbo项目 如何整合zookeeper
#### 导入依赖
\<dependency\>
\<groupId\>com.101tec\</groupId\>
\<artifactId\>zkclient\</artifactId\>
\<version\>0.9\</version\>
\</dependency\>
\<dependency\>
\<groupId\>org.apache.zookeeper\</groupId\>
\<artifactId\>zookeeper\</artifactId\>
\<version\>3.4.9\</version\>
\<type\>pom\</type\>
\</dependency\>
#### 修改服务端
<img src="../media/pictures/Dubbo.assets/image-20210126155548513.png" alt="image-20210126155548513" style="zoom:50%;" />
启动：
没有报错，
Zookeeper那边的命令行会出现一些log
#### 修改客户端
<img src="../media/pictures/Dubbo.assets/image-20210126155604203.png" alt="image-20210126155604203" style="zoom:50%;" />
#### 测试
<img src="../media/pictures/Dubbo.assets/image-20210126155618810.png" alt="image-20210126155618810" style="zoom:50%;" />
### Springboot 和 dubbo项目整合zookeeper
#### 服务端
增加了依赖
修改地址：
```
spring.application.name=dubbo-spring-boot-starter
spring.dubbo.server=true
spring.dubbo.registry=zookeeper://localhost:2181
```
启动
#### 使用端
```xml
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
<version>0.10</version>
</dependency>
```
配置文件：
增加如下：
```
spring.dubbo.registry=zookeeper://localhost:2181
```
代码里：
#### 测试
这里有一个面试题:
加入zookeeper挂掉以后,Dubbo还能不能正常调用??
可正常调用!因为本地有缓存!
## Dubbo负载均衡
### 概念
LoadBalance
中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。
### 负载均衡策略
<img src="../media/pictures/Dubbo.assets/image-20210126155639771.png" alt="image-20210126155639771" style="zoom:50%;" />
#### Random
随机加权
RandomLoadBalance
是加权随机算法的具体实现，它的算法思想很简单。假设我们有一组服务器 servers = [A,
B, C]，他们对应的权重为 weights = [5, 3,
2]，权重总和为10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区间属于服务器
A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器
C。接下来通过随机数生成器生成一个范围在 [0, 10)
之间的随机数，然后计算这个随机数会落到哪个区间上。权重越大的机器，在坐标轴上对应的区间范围就越大，因此随机数生成器生成的数字就会有更大的概率落到此区间内。
#### RoundRobin
我们有三台服务器 A、B、C。我们将第一个请求分配给服务器 A，第二个请求分配给服务器
B，第三个请求分配给服务器 C，第四个请求再次分配给服务器 A。这个过程就叫做
轮询。轮询是一种无状态负载均衡算法，实现简单，适用于每台服务器性能相近的场景下。
通常我们可以给轮询的机器设置不同的权重，经过加权后，每台服务器能够得到的请求数比例，接近或等于他们的权重比。比如服务器
A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B
会收到其中的2次请求，服务器 C 则收到其中的1次请求。
#### LeastActive
LeastActiveLoadBalance
翻译过来是最小活跃数负载均衡。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。在具体实现中，每个服务提供者对应一个活跃数
active。初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求、这就是最小活跃数负载均衡算法的基本思想。
#### ConsistentHash
### 配置
#### Random
默认配置
#### RoundRobin
##### 客户端配置
客户端服务级别
该服务的所有方法都使用roundrobin负载均衡。
客户端方法级别
如
只有该服务的hello方法使用roundrobin负载均衡。
##### 服务端配置
服务端服务级别
该服务的所有方法都使用roundrobin负载均衡。
服务端方法级别
只有该服务的该方法使用roundrobin负载均衡。
#### LeastActive
##### 补充说明
和Dubbo其他的配置类似，多个配置是有覆盖关系的：
1. 方法级优先，接口级次之，全局配置再次之。
2. 如果级别一样，则消费方优先，提供方次之。
所以，上面4种配置的优先级是:
1. 客户端方法级别配置。
2. 客户端接口级别配置。
3. 服务端方法级别配置。
4. 服务端接口级别配置。
## 补充说明
#### 启动检查
后面的check = false 就是启动检查!
```java
@Component
public class ThirdService {
//这句话相当于 url = "dubbo://localhost:20880"
@Reference(interfaceClass = DemoService.class,check = false)
DemoService demoService;
public String sendMsg(String msg){
return demoService.sendMsg(msg);
}
}
```
启动检查加了以后,我们不关心现在有没有provider,他会去检查!
#### Dubbo的特性
# 2.Guns
## Guns介绍
### 介绍
<https://gitee.com/naan1993/guns/>
- 快速构建应用系统（后台管理系统）。
- 默认提供了诸多业务系统的基本功能
- 继承了很多优秀的开源框架（开源）
- 可以直接作为一个后台管理系统的脚手架!
### 基本概念
<img src="../media/pictures/Dubbo.assets/image-20210126155700168.png" alt="image-20210126155700168" style="zoom:50%;" />
### 基本使用
这里开始搭建后台开发的架子。
#### 导入guns到IDEA
#### 如何启动guns项目
##### 运行admin模块
<img src="../media/pictures/Dubbo.assets/image-20210126155725903.png" alt="image-20210126155725903" style="zoom:50%;" />
如何修改数据源？
在Guns-admin模块里 ，有个 配置文件 application.yml
里面默认的数据源配置如下：
修改成我们自己的：
<img src="../media/pictures/Microservice.assets/89ede97f1c1d1fcdf78d604efd72cb1d.png" style="zoom:67%;" />
```
spring:
profiles: local
datasource:
url:
jdbc:mysql://127.0.0.1:3306/guns?autoReconnect=true&useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=UTC
username: root
password: 123456
db-name: guns \#用来搜集数据库的所有表
filters: wall,mergeStat
```
然后启动项目：
**登录 用户名 admin 密码 111111 可以成功登录！**
项目启动成功！
#### 初始化rest项目 （开发主要使用）
新建guns-rest数据库和里面的表
修改guns-rest的配置文件
报错，因为我们的数据库是mysql8，所以有一个配置字段不一样。
```
Caused by: com.baomidou.mybatisplus.exceptions.MybatisPlusException: Error:
GlobalConfigUtils setMetaData Fail ! Cause:java.sql.SQLException: The connection
property 'zeroDateTimeBehavior' acceptable values are: 'CONVERT_TO_NULL',
'EXCEPTION' or 'ROUND'. The value 'convertToNull' is not acceptable.
```
把 `zeroDateTimeBehavior=convertToNull`
修改为 `&zeroDateTimeBehavior=CONVERT_TO_NULL`
去掉也可以的
再次启动
缺少包：
导入一个包：
```
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
```
访问下测试链接
<http://localhost/auth?userName=admin&password=admin>
返回
```json
{"randomKey": "51656p","token": "eyJhbGciOiJIUzUxMiJ9.eyJyYW5kb21LZXkiOiI1MTY1NnAiLCJzdWIiOiJhZG1pbiIsImV4cCI6MTU1NTgyNzI2NCwiaWF0IjoxNTU1MjIyNDY0fQ.xfwl_6937X8T2etvQq6dQLuYb6ezCu4iJsAP0ggWQxn-TRuSJdoUQz0I02z4yNtVKtJbNakMwEolPp_XrbR46w"}
```
说明rest项目启动 OK！
### Rest项目的讲解
#### Rest的使用场景
APP开发 后端
前后端分离项目 后端
#### Rest新的模块的生成