微服务，什么是微服务？

微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集相互通信，是互联网时代的产物，而SOA是系统集成的产物。如果说微服务是对系统的打散，那么SOA就是对系统的整合。

微服务架构

优点

①松耦合：基于微服务架构的应用是一系列小服务集合，这些服务之间通过非具体实现的接口及非专有通信协议进行通信（比如REST），这样只要原接口没有改变，就不会对服务消费者造成任何影响。

②抽象：一个微服务对其数据结构和数据源拥有绝对的控制权，只有该服务才可以对数据做出修改，其他微服务只有通过该服务才能够访问数据。因此，该服务可以很方便地对所能提供的数据进行有效控制。

③独立：每个微服务都可以在不影响其他微服务的情况下进行编译、打包和部署，这是单体架构应用所无法做到的。

④应对用户需求的多样性：微服务架构可以让我们轻松应对不同客户的特殊需求，通过定义良好的接口，可以让不同的微服务承担不同的职责，同时快速部署上线能力可以让用户需求尽早实现。

⑤更高可用性和弹性：微服务架构可以认为是一个去中心化的应用，每一个微服务都可以随时上线或下线。这样当某个微服务出现问题时将其下线即可，其他同类型的微服务将承担其功能，对外仍旧可以提供服务，不会造成整个服务无法正常工作。

缺点

①可用性降低：微服务之间都是通过远程调用进行协作的，而远程调用的代名词就是不稳定，如果没有有效的方案，微服务架构可能会大大降低应用的可用性。当一个服务不可用时，有可能会引起级联反应，最终会造成应用的“雪崩效应”而拖垮整个应用。

②处理分布式事务较棘手：当一个用户请求的业务涉及多个微服务时，如何保障数据的一致性就成为一个棘手的问题。传统开发通常会使用两阶段提交的解决方案来解决这个问题。但对于微服务架构来说，这个解决方案并不是一个很好的选择，甚至在某些情况下很难实现。

③全能对象（God Classes）阻止业务拆分：在进行微服务拆分时可能最让人头痛的一个问题就是全能对象。几乎对于任何一个业务应用来说都可能存在一个或多个这样的全能对象。比如，对于电子商城应用中的订单就是这种对象，订单几乎会涉及电商应用中的每一个业务，它会阻止你进行业务拆分。

④学习难度曲线加大：微服务架构虽然可以将业务分解为更小、更容易开发的模式，但是也需要开发人员学习掌握一系列的微服务开发技术，加大了进入门槛，这也是非常有难度的一个挑战。

⑤组织架构变更：虽然对于单独一个微服务的部署简化了，但是整个应用部署的复杂度却提升了，需要涉及服务编排和服务治理等一系列处理，即不仅需要制定微服务之间的部署编排、关联关系、回滚计划等，还需要协调不同的团队，以及在人事组织上进行调整来适应这种变化。

微服务发展史

第一代微服务

在 TCP 出现之后，机器之间的网络通信不再是一个难题，以GFS / BigTable / MapReduce 为代表的分布式系统得以蓬勃发展。这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota 限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。

第二代微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如 Twitter 的 Finagle、Facebook 的Proxygen 以及 Spring Cloud 等等。这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

随着时代发展，看似完美的第二代微服务模式慢慢暴露，出现了一些本质问题：

其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事。

其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到。

其三，框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手。同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级。

第三代微服务

我们先了解一下，Service Mesh 就是最近非常非常火的服务网格模式，下一代微服务的标准，为什么这样说呢？

Service Mesh 服务网格模式与目前的微服务之间的调用相比，Service Mesh 的区别在于它是一个专注于服务间通信的基础设施，是一个代理，将关于服务通讯的功能抽离出来独立运行，把服务间的通讯和功能解耦出来，解决了 springCloud 暴露的问题。

当然任何东西都不可能十全十美，我们继续了解一下Service Mesh。

Service Mesh 优点

①去中心化：集中式代理变为分布式代理，避免单点故障，比如路由转发、认证鉴权由统一的网关服务变为以进程的方式和业务服务进程共存。

②跨语言：无需一个语言一个客户端，均可以HTTP、TCP、gRPC等方式通信。

③和业务解耦：将管理和运维功能从业务服务中抽离，避免中间件客户端或服务端版本升级对业务造成的影响。

④其他：不需要应用程序做大量改动。

Service Mesh 缺点

①组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销。

②组件接管了网络流量，因此服务的整体稳定性依赖于Service Mesh，同时额外引入大量服务实例的运维和管理也是一个挑战。

③以 istio 为代表说，学习成本较高，学不动。

微服务架构的技术选型

以上作为铺垫，现在开始进入主题：springCloud 和 k8s +istio 到底应该使用哪个，还是进行整合？

相信大部分写 java 的老铁们还在用 springCould 全家桶来做服务治理。但随着时代变迁，公司发展，以及容器技术给企业带来的好处，很多公司慢慢都使用容器技术，在容器炙手可热的时期，出现了一些管理容器的 k8s+istio。

尴尬的是，k8s+istio 也可以做服务治理，那不就和 springCloud 冲突了？写 java 的不用 springCould ，难道是要用 k8s 来做服务治理？心里肯定不服气，毕竟咱们又不是运维。结果去百度普及了一波发现，格局太小了。

springCloud 具有一组丰富的，高度集成的 Java 库，可以解决所有运行时的问题，并将其作为应用程序堆栈的一部分。结果，微服务本身具有库和运行时代理，可以进行客户端服务发现，负载平衡，配置更新，指标跟踪等。单例集群服务和批处理作业等模式也可以在 JVM 中进行管理，能满足中小型公司的需求，Kubernetes 是多语言的，不仅针对 Java 平台，而且以一种通用的方式针对所有语言解决了分布式计算难题。它在平台级别和应用程序堆栈外部提供用于配置管理，服务发现，负载平衡，跟踪，指标，单例，计划作业的服务。该应用程序不需要任何用于客户端逻辑的库或代理，并且可以用任何语言编写。

在某些方面，两个平台都依赖于类似的第三方工具。例如，ELK和EFK 堆栈，跟踪库等。某些库（例如 Hystrix 和 Spring Boot ）在两种环境下都同样有用。在某些领域中，两个平台是互补的，并且可以组合在一起以创建更强大的解决方案（ KubeFlix 和 Spring Cloud Kubernetes 就是这样的示例）

对比 SpringCloud 和 istio

实践总结

1、springCloud 和 k8s +istio 可以整合，虽然功能冲突，但以 java 来说，可以先使用 springCloud 再慢慢转向 k8s+istio。

2、springCloud-nacos + k8s +istio，nacos 做服务注册，其他走 k8s +istio。

3、根据实际业务和公司发展来进行技术选型、避免盲目追新。

下期跟大家介绍一个轻量级的对象存储系统，敬请期待~

欢迎各位关注、留言，大家的支持就是我的动力！