1.什么是微服务？
微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个微服务组成，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和出现故障的时候不会相互影响。
2. 大型电商平台的微服务功能图
每个模块都可以称之为一个微服务
总结： 微服务架构是把一个大的系统按照不同的业务单元分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统，各个小的系统是独立部署的，它们之间是松耦合的。
3.为什么要用微服务？
1、单体架构扩展性差、维护成本高、不可靠
互动：什么是单体架构？
- 在单体架构下修改代码，需要把整个代码重新编译，重新部署，这个时间周期会很长
- 单体架构下的所有代码模块都耦合在一起，代码量大，维护困难，想要更新一个模块的代码，也可能会影响其他模块，不能很好的定制化代码。 所有模块都用同一个数据库，存储方式比较单一。
- 微服务中可以有 java 编写、有 Python 编写的，他们都是靠 restful 架构风格统一成一个系统的，所以微服务本身与具体技术无关是一种风格、扩展性强。（每个模块可以使用不同的语言进行开发，和代码本身无关，每个模块使用独立的开发语言去管理）
- 如果是单体架构，那么所有的模块都需要使用一种语言来开发，比如Java或者go,不可能一个代码里面写多种语言，拆分开来就可以使用多种语言
总结：可以解耦合，以及支持多种开发语言，维护起来特别简单
4.单体应用 vs 微服务
5.微服务特性
1）灵活部署、独立扩展
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如订单服务，商品服务）为单位进行部署，修改订单服务的代码对商品服务是没有影响的，只需要对要修改的服务重新更新打包编译就行了。
2）资源的有效隔离
每一个微服务拥有独立的数据源，假如微服务 A 想要读写微服务 B 的数据库，只能调用微服务 B 对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。另外微服务各模块部署在 k8s 中，可以进行 CPU、内存等资源的限制和隔离。
3）高度可扩展性
随着某些服务模块的不断扩展，可以跨多个服务器和基础架构进行部署，充分满足业务需求。
4）易于部署
相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，且易于部署。
5）服务组件化
在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过 HTTP等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。
6）去中心化治理
在整个微服务架构，通过采用轻量级的契约定义接口，使得我们对服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。
7)容错设计
在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录。比如对服务状态、断路器状态、吞叶量、网络延迟等关键数据进行可视化展示。
8）技术栈不受限
在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。
9）局部修改容易部署
单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
10）易于开发和维护
一个微服务只会关注一个特定的业务功能，所以它的业务清晰，代码量较少
6.什么样的项目适合使用微服务？
在复杂度比较低的项目中，单体架构就可以满足需求，而且部署效率也会比较高（部署一个tomcat，那么在k8s当中直接部署一下就行了，不需要开发一些代码），在复杂度比较高的项目
中，单体架构就不能满足了，需要进行微服务化。
微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强
制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔 离，所以无法做到独立部署和运行，也就不适合做成微服务了。
那到底什么样的项目适合微服务呢？
1. 业务并发量大，项目复杂，访问流量高，为了将来更好的扩展，随时对代码更新维护，可以使用微服务
2. 代码依赖程度高，想要解耦合，交给多个开发团队维护
3. 业务初期，服务器数量少，可以使用微服务，能有效节省资源。
4. 从思想上： 对未来有清晰的认识，对技术更新要保持着一种自信，超前思维，知道这个东西在将来肯定会发展起来。
这就告诉了我们一个道理，在学习技术的时候，适合自己的才是最好的，比方说很多人说我们公司单体架构用的也挺好的啊，为什么还要用微服务，其实他们再用单体可能适合他们业务需求，但是我们公司可能业务规模大，项目复杂，我就想要用微服务，或者我们在未来上有更大的远见，那我也会选择用微服务，不要说看别人用，我也用，而是我用是符合我们实际需求的，一切脱离实际业务的微服务都是耍流氓。
微服务框架标准
通过服务组件化：微服务架构也会使用软件库，但是用来实现软件组件化的主要方式是将软件拆分成服务。
围绕业务能力组织：微服务采用不同的分割方法，划分成围绕业务能力组织的服务。这些服务采取该业务领域软件的宽栈实现，包括用户接口、持久化存储和任何外部协作。因此，团队都是跨职能的，包括开发需要的全方位技能：用户体验、数据库、项目管理。
是产品不是项目：开发团队负责软件的整个产品周期。开发者需要接触他们的软件在生产环境如何工作，并增加与他们的用户联系，同时他们必须承担至少部分的支持工作。
智能端点和哑管道：基于微服务构建的应用程序的目标是尽可能的解耦和尽可能的内聚。
去中心化治理：服务之间只需要约定接口，而无需关注彼此的内部实现。同样的，运维只需要知道服务的部署规范就可以部署了。
去中心化数据管理：微服务架构强调服务间的无事务协作，对一致性可能只是最后一致性和通过补偿操作处理问题有明确的认知。
基础设施自动化：广泛使用基础设施自动化，运行大量的自动化测试，促进工作软件沿流水线向前，自动化部署到各个环境中。
微服务核心模式
模式语言提供了讨论问题的交流术语，它明确了特定场景、特定问题的解决方案和延伸性思考。模式语言主要目的是帮助开发者解决在设计和编程中遇到的共同的问题，即清晰的问题陈述、体现问题的解决方案以及推动解决方案的力量(Force)的清晰表述。微服务架构作为一个现在流行的服务架构，也有一套属于自己的模式。
182
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
