@HUST-SuWB
2020-05-13T10:12:13.000000Z
字数 6781
阅读 329
美团
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。形像一点来说，微服务架构就像搭积木，每个微服务都是一个零件，并使用这些零件组装出不同的形状。如果学科派一点，微服务架构就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为 HTTP RESTful API）实现通信。
微服务的概念源于2014年3月Martin Fowler所写的一篇文章Microservices。
微服务架构的优点：
微服务架构的缺点：
一个完整的微服务架构包含很多组件，其中典型的有：
RPC 框架的目标就是让远程服务调用更加简单、透明，RPC 框架负责屏蔽底层的传输方式（TCP 或者 UDP）、序列化方式（XML/Json/ 二进制）和通信细节。服务调用者可以像调用本地接口一样调用远程的服务提供者，而不需要关心底层通信细节和调用过程。
RPC框架的职责是：
业界主流的 RPC 框架：
Feign是SpringCloud提供的一种跨进程的服务调用方式，不过Feign并不是严格意义上的RPC框架，因为Feign实现的是基于HTTP协议的Restful风格的服务调用。
Eureka是Netflix开源的一款提供服务注册和发现的产品，它是Spring Cloud体系中最重要最核心的组件之一。
Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。
Ribbon，主要提供客户侧的软件负载均衡算法。Ribbon内置可插拔、可定制的负载均衡组件。下面是用到的一些负载均衡策略：
随着微服务不断的增多，每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境、生产环境，因此每个微服务又对应至少三个不同环境的配置文件。这么多的配置文件，如果需要修改某个公共服务的配置信息，如：缓存、数据库等，难免会产生混乱，这个时候就需要引入Spring Cloud另外一个组件：Spring Cloud Config。
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client通过接口获取数据、并依据此数据初始化自己的应用。
在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
在这种情况下就需要整个服务机构具有故障隔离的功能，避免某一个服务挂掉影响全局。在Spring Cloud 中Hystrix组件就扮演这个角色。
Hystrix会在某个服务连续调用N次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。
在典型的微服务架构中，应用服务器一般需要额外实现下面这些功能：
但其实这些都不是业务功能，所以互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能，而业务线的技术部门直接使用相关框架、工具与平台，享受各种“黑科技”带来的便利。
理想很丰满，现实却很骨感，由于：
往往会面临以下一些问题：
这些耦合，这些通用的痛点，有没有办法解决呢？一个思路是，将服务拆分成两个进程，解耦。一个进程实现业务逻辑（不管是调用方，还是服务提供方），biz，一个进程实现底层技术体系，proxy。这样，负载均衡、监控告警、服务发现与治理、调用链等诸多基础设施，都放到这一层实现。biz和proxy共同诞生，共同消亡，互为本地部署。biz和proxy之间，为本地通讯。所有biz之间的通讯，都通过proxy之间完成，proxy之间才存在远端连接。这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个服务集群变成了网格状，这就是Service Mesh。
Service Mesh又译作“服务网格”，作为服务间通信的基础设施层。如果用一句话来解释什么是Service Mesh，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用Service Mesh也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如Spring Cloud、OSS，现在只要交给Service Mesh就可以了。
Service Mesh有如下几个特点：
蚂蚁金服 Service Mesh 实践探索
对于 Service Mesh，我们有一个重要判断，这也是今天最想和大家分享的一点：Service Mesh 的归宿，或者说最终的形态，是下沉到基础设施！
第一步：从应用剥离
通过将原有的方法调用改为远程调用，将类库的功能套上 Proxy 的壳子，Service Mesh 成功的将服务间通讯从程序中剥离出来，从此服务间通讯不再是应用程序的一部分。
这一点是大家最容易接受的，对吧？这一步也是最容易实现的，只要搭起来一个 Sidecar 或者说 Proxy，将原有类库的功能塞进去就好了。
第二步：下沉为抽象层
这些剥离出来的服务间通讯的能力，在剥离之后，开始下沉，在应用程序下形成一个单独的抽象层，成为 服务间通讯专用基础设施层。此时，这些能力以一个完成的形态出现，不再存在单独的类库或者框架形式。
第二步和第一步往往是一脉相承的，一旦走出了第一步，自然而然会继续。因为服务间通讯被抽取出来之后，继续往前发展，就会很自然地把它就变成一个基础设施层。
第三步：融入基础设施
继续下沉，和底层基础设施密切联系，进而融为一体，成为平台系统的一部分，典型就是和 kubernetes 结合。
Kubernetes已经成为了容器调度编排的事实标准，而容器正好可以作为微服务的最小工作单元，从而发挥微服务架构的最大优势。所以我认为未来微服务架构会围绕Kubernetes展开。而Istio和Conduit这类Service Mesh天生就是为了Kubernetes设计，它们的出现补足了Kubernetes在微服务间服务通讯上的短板。虽然Dubbo、Spring Cloud等都是成熟的微服务框架，但是它们或多或少都会和具体语言或应用场景绑定，并只解决了微服务Dev层面的问题。若想解决Ops问题，它们还需和诸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes这类资源调度框架做结合。服务网格并不是和Kubernetes一起出现。然而，因为有Kubernetes，服务网格更容易被引入到你的环境中。
冗余冗余冗余！！！
高并发相关的常见指标有哪些？
互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）和水平扩展（Scale Out）。
垂直扩展是指，提升单机处理能力，垂直扩展的方式又有两种：
1. 增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；
2. 提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
水平扩展是指通过增加服务器数量，线性扩充系统性能。各层次水平扩展的实践又有所不同：
1. 反向代理层可以通过“DNS轮询”的方式来进行水平扩展；
2. 站点层可以通过nginx来进行水平扩展；
3. 服务层可以通过服务连接池来进行水平扩展；
4. 数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；