微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个微服务组成，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和出现故障的时候不会相互影响。
总结： 微服务架构是把一个大的系统按照不同的业务单元分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统，各个小的系统是独立部署的，它们之间是松耦合的。
1、单体架构扩展性差、维护成本高、不可靠
互动：什么是单体架构？
在单体架构下修改代码，需要把整个代码重新编译，重新部署，这个时间周期会很长；
单体架构下的所有代码模块都耦合在一起，代码量大，维护困难，想要更新一个模块的代码，也可能会影响其他模块，不能很好的定制化代码。
所有模块都用同一个数据库，存储方式比较单一。
2、微服务中可以有java编写、有Python编写的，他们都是靠restful架构风格统一成一个系统的，所以微服务本身与具体技术无关、扩展性强
1）灵活部署、独立扩展
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如订单服务，商品服务）为单位进行部署。
2）资源的有效隔离
每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。另外微服务各模块部署在k8s中，可以进行CPU、内存等资源的限制和隔离。
3）高度可扩展性
随着某些服务模块的不断扩展，可以跨多个服务器和基础架构进行部署，充分满足业务需求。
4）易于部署
相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，且易于部署。
5）服务组件化
在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。
6）去中心化治理
在整个微服务架构，通过采用轻量级的契约定义接口，使得我们对服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。
7）容错设计
在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录。比如对服务状态、断路器状态、吞吐量、网络延迟等关键数据进行可视化展示。
8）技术栈不受限
在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。
9）局部修改容易部署
单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
10）易于开发和维护
一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量较少。
在复杂度比较低的项目中，单体架构就可以满足需求，而且部署效率也会比较高，在复杂度比较高的项目中，单体架构就不能满足了，需要进行微服务化。
微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。
那到底什么样的项目适合微服务呢？
1. 业务并发量大，项目复杂，访问流量高，为了将来更好的扩展，随时对代码更新维护，可以使用微服务
2. 代码依赖程度高，想要解耦合，交给多个开发团队维护
3. 业务初期，服务器数量少，可以使用微服务，能有效节省资源。
4. 从思想上： 对未来有清晰的认识，对技术更新要保持着一种自信，超前思维，知道这个东西在将来肯定会发展起来。
这就告诉了我们一个道理，在学习技术的时候，适合自己的才是最好的，比方说很多人说我们公司单体架构用的也挺好的啊，为什么还要用微服务，其实他们再用单体可能适合他们业务需求，但是我们公司可能业务规模大，项目复杂，我就想要用微服务，或者我们在未来上有更大的远见，那我也会选择用微服务，不要说看别人用，我也用，而是我用是符合我们实际需求的，一切脱离实际业务的微服务都是耍流氓。
服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。
在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发，例如在大促的情况下，有些功能需要降级，哪些功能可以降级，哪些功能不能降级，都可以在配置文件中统一配置。
1）系统和应用的监控
监控系统和服务的健康状态和性能瓶颈，当系统出现异常的时候，监控系统可以配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。
2）调用关系的监控
对代码调用关系进行监控
6.3 日志收集
业务层面、代码层面、系统层面
第一代微服务框架
SpringCloud
SpringCloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现注册、熔断器、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态、负载均衡、数据监控等）
第二代微服务框架
dubbo
dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案
第三代微服务框架
1.ServiceMesh（服务网格）、k8s
istio是开源的ServiceMesh（服务网格），ServiceMesh翻译成中文就是服务网格
来源于SpringSource ，具有Spring社区的强大背景支持，还有 Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架开源贡献给了社区，这些框架开源的整套微服务架构套件是SpringCloud的核心。
Eureka: 服务注册发现框架；
Zuul: 服务网关；
Karyon: 服务端框架；
Ribbon: 客户端框架；
Hystrix: 服务容错组件；
Archaius: 服务配置组件；
Servo: Metrics组件；
Blitz4j: 日志组件。
Pinpoint：全链路监控组件
是一个分布式服务框架，是国内互联网公司开源做的比较不错的阿里开放的微服务化治理框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。 其核心部分包含（官网）:
远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo也是采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用 Spring加载Dubbo的配置即可，Dubbo 基于Spring的Schema扩展进行加载。当然也支持官方不推荐的 API 调用方式。
作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行公司、Uber劲敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前是针对 Kubernetes 环境的，社区宣称在未来几个月内会为虚拟机和 Cloud Foundry 等其他环境增加支持。 Istio 将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础。
HTTP、gRPC 和 TCP 网络流量的自动负载均衡；
提供了丰富的路由规则，实现细粒度的网络流量行为控制；
流量加密、服务间认证，以及强身份声明；
全范围（Fleet-wide）的策略执行；
深度遥测和报告。
开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。
查看下在Github上的更新时间
SpringCloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。
Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。
istio：istio · GitHub → 所有项目均更新于『30 分钟』内。
可见，项目在社区活跃度上，Istio > SpringCloud > Dubbo，结合稳定性来看，对于使用 Java 开发业务较多的企业，SpringCloud是相对更优的选择，对于更多企业来说，与语言几乎无绑定的Istio也是可以好好期待一下其在社区的发展。
总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud是目前阶段发展最早的微服务框架方案，Istio 作为Kubernetes 的优先支持来讲，也是一个值得关注的方案，而且发展潜力巨大，相信不久的将来90%+的k8s用户都会使用istio。目前对比来看，dubbo则显得稍逊下来。
原文：https://www.cnblogs.com/dahuige/p/15114887.html