微服务笔记

微服务架构

1. 各个服务的开发、测试、部署都相互独立，就是传统的单服务拆分成多个服务，比如用户服务就可以拆分做为一个单独的服务，而他的开发也不用依赖于其他服务，如果用户量很大，可以很容易的进行负载。
2. 当一个新的需求出现时，特别是在一个庞大的项目系统中心，你得去考虑各方面的问题，兼容性、影响度等等,而使用微服务则可以直接跳过这些费时又烧脑的环节。
3. 使用微服务将项目进行拆分之后，各服务之间就消除了很多限制，只需要保证对外提供的接口正常可用即可，至于使用的什么语言、什么框架都不需要关心。
4. 跨系统、分布式事务、易开发，易维护

–（SpringCloud） rest API

单体项目的弊端

1. 随着业务的发展，开发变得越来越复杂
2. 修改、新增某个功能，需要对整个系统进行测试、重新部署
3. 一个模块出现问题，很有可能导致整个系统奔溃
4. 多个开发团队同时对数据数据进行管理，容易产生安全漏洞
5. 各个模块使用同一种技术进行开发，各模块很难根据实际情况选择更适合的技术框架，局限性很大
6. 模块内容过于复杂，如果员工离职，可能需要很长实际才能完成工作交接

分布式、集群

集群：一台服务器无法负荷高并发的数据访问量，那么就设置十台服务器一起分担压力，十台不行就设置一百台（物理层面）。很多人干同一件事情，来分摊压力。

分布式：将一个复杂的问题拆分成若干个简单的小问题，将一个大型的项目架构拆分成若干个微服务来协同完成。（软件设计层面）将一个庞大的工作拆分成若干个小步骤，分别有不同的人完成这些小步骤，最终将所有的结果进行整合实现大的需求。

服务治理的核心

1. 服务治理的核心分为三部分组成：服务提供者、服务消费者、注册中心。
2. 在分布式系统架构中心，每个微服务在启动时，将自己的信息存储在注册中心，叫做服务注册。
3. 服务消费者从注册中心获取服务提供者的网络信息，通过该信息调用服务，叫做服务发现。

nacos注册中心

1. nacos可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系，所有要进行注册的微服务通过客户端连接到nacos完成注册。
2. 注册中心就相当于一个电商平台，服务提供者相当于卖家在这个平台上面注册了一个店铺，提供了一个出售商品的服务；服务消费者就相当于在这个平台上注册一个账号，然后就可以这个平台各个的店铺中购买商品。
3. service{ip：9000；ip2：9001}

注册中心构图

Spring Cloud架构