什么是六边形架构“六边形架构”是 Cockburn大牛在2005年 提出的。该架构提供了一种将业务逻辑和具体输入输出技术分离的模式。 为什么采用微服务现在大多数开发一个应用,哪怕是类似Uber或者淘宝的应用。基本上都是已单体模式开发。虽然在应用自身架构上采用了模块化设计,但在本质上他还是一个单体应用。 例如:如下图 这样的单体应用不好吗?上图,是比较经典优秀的单体六边形架构。在很多公司实际上因为各种原因单体应用架构还没有达到这个水平。所以会有以下几个方面问题 1. 整体扩展性差,当应用越来越庞大后,进行新功能开发或者功能修改将会很困难。 2. 整体耦合度高,一样当应用庞大。解耦将是一个叫你头疼的问题。 3. 复杂度高,维护性差。当他足够庞大。新来的同事将会接手一个对他们看来是个怪物的东西,你会听到这些抱怨。这都是什么??你们到底在想什么?? 4. 性能低下,因为各种原因,主要是开发人员水平不一。你会发现整个应用越来越慢,你想找到原因变的越来越困难。代码有大量沉余,你每天都在纠结是 否可以重建他(不是重构!!)。 为什么要采用微服务?不能直接采用比较高级的架构吗?微服务实际上就是用多个单体应用的集合。用多个单体服务来处理一些复杂业务。在实际开发中,除了架构师,对单个开发人员来说他只是需要开发一个简单的单体应用。开发门槛比较低,你以为在成都,西安等这些二三线城市高水平的程序员是那么好找的吗?(二三线小城市公司开不起工资,理解高级架构的高级程序员至少20,30K工资)。 综上,微服务将是解决二三线小城市,小公司问题的一个优秀方案。 什么是微服务?微服务开发团队怎么组建?上文已经说了,微服务实际就是多个单体应用的集合。那么一个微服务开发团队需要那些人员呢?下面我就说下我的理解。 一个微服务最小开发团队: 首先明确开发基础环境。既然微服务了。那么你的应用已经不是一个简单的服务可以满足需求或者你设想中的业务是需要一个服务平台才能解决的。那么最小配置将需要以下岗位。 项目经理:他会负责产品开发进度把控等等。优秀的项目经理决定你团队的战斗力。 产品经理:一个优秀的产品经理可以快速把你的想法或者用户的需要精确形成各种需求,他是不可或缺的。 架构师: 一个精通各种设计理论,有丰富一线开发经验并且了解微服务的架构师他将是整个团队的核心。决定你整个产品的质量。 核心高级工程师: 他将会负责整个微服务开发门槛最高的API Gateway服务的人选。他的好坏直接决定你的产品性能。 高级工程师: 他是带领开发小组进行具体开发的人选。他决定了代码质量和单个单体应用的性能。 初中级工程师: 他们将是大多数具体功能开发者。在高级工程师的指导下开发出符合要求的代码,同时也是公司的后备人才,人才储备。 微服务的架构是什么?我先展示一个最粗粒度的微服务架构,然后我们在一起一步一步完善它。 为什么采用API Gateway?对应用来说,不管你怎么变化技术。实际处理的业务可以抽象成一句话,客户端请求服务返回数据并向客户展示。客户端与服务端的通信我们常见的有两种方式。 1. 客户端直接跟服务端通信。 2. 客户端通过API Gateway 跟服务端通信。 理论上说,一个客户端可以直接给多个微服务中的任何一个发起请求。每一个微服务都会有一个对外服务端。这个URL可能会映射到微服务的负载均衡上,它再转发请求到具体节点上。为了搜索产品细节,移动端需要向上述微服务逐个发请求。 通常来说,一个更好的解决办法是采用API Gateway的方式。API Gateway是一个服务器,也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构,并且提供API给各个客户端。它还可能有其他功能,如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。 API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API Gateway,然后路由这些请求到对应的微服务。API Gateway将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在web协议与内部使用的非Web友好型协议间进行转换,如HTTP协议、WebSocket协议。 API Gateway的优点和缺点如你所料,采用API Gateway也是优缺点并存的。API Gateway的一个最大好处是封装应用内部结构。相比起来调用指定的服务,客户端直接跟gatway交互更简单点。API Gateway提供给每一个客户端一个特定API,这样减少了客户端与服务器端的通信次数,也简化了客户端代码。 实现一个API Gateway既然我们已经知道了采用API Gateway的动机和优缺点,下面来看在设计它时需要考虑哪些事情。 性能和可扩展性只有少数公司需要处理像Netflix那样的规模,每天需要处理数十亿的请求。但是,对于大多数应用,API Gateway的性能和可扩展性也是非常重要的。因此,创建一个支持同步、非阻塞I/O的API Gateway是有意义的。已经有不同的技术可以用来实现一个可扩展的API Gateway。在JVM上,采用基于NIO技术的框架,如Netty,Vertx,Spring Reactor或者JBoss Undertow。Node.js是一个非JVM的流行平台,它是一个在Chrome的JavaScript引擎基础上建立的平台。一个可选的方案是NGINX Plus。NGINX Plus提供一个成熟的、可扩展的、高性能web服务器和反向代理,它们均容易部署、配置和二次开发。NGINX Plus可以管理授权、权限控制、负载均衡、缓存并提供应用健康检查和监控。 采用反应性编程模型对于有些请求,API Gateway可以通过直接路由请求到对应的后端服务上的方式来处理。对于另外一些请求,它需要调用多个后端服务并合并结果来处理。对于一些请求,例如产品最终页面请求,发给后端服务的请求是相互独立的。为了最小化响应时间,API Gateway应该并发的处理相互独立的请求。但是,有时候请求之间是有依赖的。API Gateway可能需要先通过授权服务来验证请求,然后在路由到后端服务。类似的,为了获得客户的产品愿望清单,需要先获取该用户的资料,然后返回清单上产品的信息。这样的一个API 组件是Netflix Video Grid。 服务调用一个基于微服务的应用是一个分布式系统,并且必须采用线程间通信的机制。有两种线程间通信的方法。一种是采用异步机制,基于消息的方法。这类的实现方法有JMS和AMQP。另外的,例如Zeromq属于服务间直接通信。还有一种线程间通信采用同步机制,例如Thrift和HTTP。事实上一个系统会同时采用同步和异步两种机制。由于它的实现方式有很多种,因此API Gateway就需要支持多种通信方式。 服务发现API Gateway需要知道每一个微服务的IP和端口。在传统应用中,你可能会硬编码这些地址,但是在现在云基础的微服务应用中,这将是个简单的问题。基础服务通常会采用静态地址,可以采用操作系统环境变量来指定。但是,探测应用服务的地址就没那么容易了。应用服务通常动态分配地址和端口。同样的,由于扩展或者升级,服务的实例也会动态的改变。因此,API Gateway需要采用系统的服务发现机制,要么采用服务端发现,要么是客户端发现。后续的一篇文章将会更详细的介绍这部分。如果采用客户端发现服务,API Gateway必须要去查询服务注册处,也就是微服务实例地址的数据库。 处理部分失败在实现API Gateway过程中,另外一个需要考虑的问题就是部分失败。这个问题发生在分布式系统中当一个服务调用另外一个服务超时或者不可用的情况。API Gateway不应该被阻断并处于无限期等待下游服务的状态。但是,如何处理这种失败依赖于特定的场景和具体服务。例如,如果是在产品详情页的推荐服务模块无响应,那么API Gateway应该返回剩下的其他信息给用户,因为这些信息也是有用的。推荐部分可以返回空,也可以返回固定的顶部10个给用户。但是,如果是产品信息服务无响应,那么API Gateway就应该给客户端返回一个错误。 |
|
来自: 王宇w3j0f3o2vv > 《待分类》