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

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

猜你喜欢

转载自blog.csdn.net/qq_41708993/article/details/122992924