微服务基础知识
Last updated on 9 months ago
微服务基础知识
什么是微服务
先说百度百科给的定义
一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的Restful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
结合网上大佬的帖子，光说微服务体会不到微服务，有人说的对，聊到概念，应该是从现有的单体应用与微服务架构进行比较才能得出结论。
传统架构&微服务架构
微服务的优点
- 微服务是松藕合的，无论是在开发阶段或部署阶段都是独立的。
- 能够快速响应, 局部修改容易, 一个服务出现问题不会影响整个应用。
- 易于和第三方应用系统集成, 支持使用不同的语言开发, 允许你利用融合最新技术。
- 每个微服务都很小，足够内聚，足够小，代码容易理解。团队能够更关注自己的工作成果, 聚焦指定的业务功能或业务需求。
- 开发简单、开发效率提高，一个服务可能就是专一的只干一件事, 能够被小团队单独开发，这个小团队可以是 2 到 5 人的开发人员组成。
微服务的缺点
- 由于服务增加，复杂性同时增加，在生产环境中项目涉及到的微服务数量会很庞杂，尤其是在微服务之间的互相调用。
- 资源一致性
- 运维成本增加，也就是需要更多的
DevOps操作 - 由于分布式部署问题追踪问题难
设计原则
单一职责：每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑
服务自治：每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
轻量级通信：首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
接口明确：由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
