微服务架构与springcloud 01——微服务入门

微服务概述

• 1.1 为什么是微服务
• 1.2 微服务架构
• 1.3 微服务与其它技术
• 1.4 技术选型
• 1.5主流组件

1.1 为什么是微服务

数字化生活提倡万物互联，一个家庭可能会有手机、电脑、平板、家电等等，如果这些东西都来自不同的产商，那么他们之间的连结肯定不会特别容易。如果有一个产商可以把这些产品都来个全家桶，数字化生活就便利了，小米、华为、苹果，很多公司都在做这样的事情。

而在互联网的项目中，技术日新月异、项目的功能模块也越来越多，网关、日志、容错、授权…这些不同厂家推出的不同的框架、技术五花八门.

同时，传统系统随着业务需求、bug叠加，就会像滚雪球一样，越滚越大，越来越臃肿；而且不同模块可能用不同的语言、技术更合适，传统的编程模式无法实现。

微服务快马加鞭而来，传统编程像一碗面条，纠缠不清。而它就像一盘水饺，一个个小业务都是一个水饺，彼此能够独立。

除此之外，微服务把模块之间的界限画的棱角分明，不同模块之间灵活调用，A、B都需要做日志监控，以往可能需要各个模块各自实现，而现在可以统一调C模块实现。

现在来有请微服务C位出道！

image-20220217210555588

它的特点是：可扩展性、模块化、各个模块能够单独开发、部署、扩展、维护。

微服务也有很多缺点：性能略下降、事务问题、跨服务协作、难度大需要全面团队…

微服务适应于复杂的项目，可扩展性要求很强的项目、有一定规模的创业公司(需要不断的迭代业务试错)

1.2 微服务架构

image-20220217212551018

可参考《MicroServices Patterns》，在这里讲解重点的几个模块。

1）服务发现(Service Discovery):服务注册中心、服务查询、服务监控、数据同步、API Service、取消、更新、获取…

2）服务路由:Routing、Load Balancer、安全、熔断、Error Handling、Monitoring、Tracing、Rate Limit…

3）服务配置:配置服务、配置管理、Admin UI、Config Adapter、Config Refresh…

4）Circuit Breaker：closed、Open、Half-Open（这个模块其实就是一个调度机制，防止各个模块调用时由于某个模块的故障导致其它模块奔溃）

5）Security

6）服务通信:同步模式、异步模式

7）数据一致性:锁机制(微服务并发量大起来会卡在这)—>Try-Comfirm -Cancel(性能更好，但是三部分代码实现具有一定难度)—>SAGA(异步、主流、不会被锁、可能出现幻读)

1.3 微服务与其它技术

Docker是一种容器化的技术，微服务只有容器化技术结合才能称为微服务，一定要学习。Kubernetes用于大规模容器化集群，不熟悉Kubnetes则微服务寸步难行。分布式配置、服务发现、升级等都可以在Kubernetes进行管理。微服务中测试也十分重要，包含：Unit Testing、integreation Testing、Component Testing、Contract Testing、E2E/Performances Testing。

对于app、平台、体系系统都需要全面的监测，需要Monitor。微服务的日志需要进行集中管理，LogStash+ElasticSearch+Kibana可以很好的把日志进行管理。同时也需要Tracing工具，因为微服务中调用过程十分复杂，没有Tracing机制定位问题十分困难，MQ可以进行Tracing。

1.4 技术选型

由于JVM的负担较大，对于大型项目Go语言实现微服务更加轻便，而对于一些中型项目实现微服务，有庞大的java、spring生态群，我们往往通过Spring boot+Spring Cloud实现。常用的微服务模式都在spring cloud中都得以实现。Spring cloud 是在spring boot的基础上发展起来的。

springboot官网强烈建议升级到2.0版本以上。访问官网Spring Cloud可以看到springcloud与springboot版本对应关系。

image-20220217213526252

官网有更加详细的说明，本教程使用的技术选型如下。

image-20220217214659407

1.5主流组件

cloud组件由于很多原因(包括不限于技术人员的进ICU、跳槽、互撕…)停更不停用，目前我们比较主流的组件如下。

image-20220217215927289