微服务架构
- 各个服务的开发、测试、部署都相互独立,就是传统的单服务拆分成多个服务,比如用户服务就可以拆分做为一个单独的服务,而他的开发也不用依赖于其他服务,如果用户量很大,可以很容易的进行负载。
- 当一个新的需求出现时,特别是在一个庞大的项目系统中心,你得去考虑各方面的问题,兼容性、影响度等等,而使用微服务则可以直接跳过这些费时又烧脑的环节。
- 使用微服务将项目进行拆分之后,各服务之间就消除了很多限制,只需要保证对外提供的接口正常可用即可,至于使用的什么语言、什么框架都不需要关心。
- 跨系统、分布式事务、易开发,易维护
–(SpringCloud) rest API
单体项目的弊端
- 随着业务的发展,开发变得越来越复杂
- 修改、新增某个功能,需要对整个系统进行测试、重新部署
- 一个模块出现问题,很有可能导致整个系统奔溃
- 多个开发团队同时对数据数据进行管理,容易产生安全漏洞
- 各个模块使用同一种技术进行开发,各模块很难根据实际情况选择更适合的技术框架,局限性很大
- 模块内容过于复杂,如果员工离职,可能需要很长实际才能完成工作交接
分布式、集群
集群:一台服务器无法负荷高并发的数据访问量,那么就设置十台服务器一起分担压力,十台不行就设置一百台(物理层面)。很多人干同一件事情,来分摊压力。
分布式:将一个复杂的问题拆分成若干个简单的小问题,将一个大型的项目架构拆分成若干个微服务来协同完成。(软件设计层面)将一个庞大的工作拆分成若干个小步骤,分别有不同的人完成这些小步骤,最终将所有的结果进行整合实现大的需求。
服务治理的核心
- 服务治理的核心分为三部分组成:服务提供者、服务消费者、注册中心。
- 在分布式系统架构中心,每个微服务在启动时,将自己的信息存储在注册中心,叫做服务注册。
- 服务消费者从注册中心获取服务提供者的网络信息,通过该信息调用服务,叫做服务发现。
nacos注册中心
- nacos可以说是微服务架构中的”通讯录“,它记录了服务和服务地址的映射关系,所有要进行注册的微服务通过客户端连接到nacos完成注册。
- 注册中心就相当于一个电商平台,服务提供者相当于卖家在这个平台上面注册了一个店铺,提供了一个出售商品的服务;服务消费者就相当于在这个平台上注册一个账号,然后就可以这个平台各个的店铺中购买商品。
- service{ip:9000;ip2:9001}