作者介绍
花名聪心，阿里云技术专家，主要负责阿里云OpenAPI，Services architectre 技术服务的实现。
云产品前端架构
众所周知，阿里是以 Java 开发为主，最近引用 GO 在微服务架构上面进行开发，本次分享也是围绕这个主题进行叙述。
图 1
图 1 所示，是我们最早期的前端微服务架构图，当时不存在API网关服务、天象全链路监控以及外部服务这几个模块，并且蓝色这部分也并没有被应用起来。因此进行了一场微服务重构过程，产生了最新的前端微服务架构图（图 2）。
图 2
图 2 是目前的前端微服务架构，其中，OpenAPI是前端入口；API网关目前被商业化，由它来调度内部的dubbo服务；其次是最为重要的中间件，由其支撑注册中心、控制台、阿里云日志服务、消息队列服务以及内部的天象全链路监控系统；外部服务主要是进行与其他云产品的交互，比如VPC、VPS等；驱动&接口服务也进一步的开发应用起来。下面着重介绍整个架构中的几个板块。
* 日志服务
图 3
在这么多微服务组件中，日志采集是不可或缺的，阿里云日志服务对象就是ELK，实际上它的成本是比较高的，而使用Kafka则成本要相对低很多。现在会提供很多中间的服务进行协调，方便进行业务统计工作（图 3）
* API网关服务
图 4
网关服务位于整个架构的最上层；因为认证系统的存在，所以再使用老架构的形式则每一个对外服务都需要我们自己手动进行接入，这样会耗费很大的工作量，所以新版的架构将API网关服务放在最上层，一方面在认证服务方面省去了人力成本其次在流量控制上，也起到了关键性的作用（图 4）。
天象全链路监控系统
图 5
图 5 所示是天象全链路监控系统的界面，这一块在整个微服务架构中是不可或缺的一个服务。当架构微服务化后往往会造成链路变长的情况发生（图左所示）。使用天象可以对全链路进行监控。
Dubbo
Dubbo是一个RPC框架，在11-12年间名气都是比较响的，当时它有2000个节点，3B+ request，在阿里巴巴、京东以及当当网的使用度是比较高的。它最实用的地方主要在于以下几点：
1、服务动态注册&服务发现
2、SOA服务治理
3、转负载均衡
4、熔断、服务降级
图 6
图 6 所示是Dubbo服务治理图。其中包括了调度中心、监控中心、注册中心、治理中心这几项服务，如果要做到100%规范，那么图中的每个点都需要去遵守。因为阿里目前只有几百个节点，所以可以很放心的使用这个框架而不需要担心它有任何的性能问题。
图 7
图 7 所示。是讲Dubbo部署到可服务化的一个示意图，当应用起来后会启动 Repository，接下来comsumer便会开始服务了，所有应用都会收到通知，不管新版本、新接口或是新的服务器上线都会接收到通知。此时如果需要调用，便会去寻求最适合的方式；在此之上的Monitor，也会持续回报运维人员。其实关于Dubbo的未来规划，就是可以解决所有SOA的事情，目前还是人工的在执行这件事情，没有施行自动化方案，这也是有遗留的历史因素存在。
Micro-services complexity at 阿里云
阿里云前端架构的微服务化是一个必然的趋势，早在2014年业务增长并不显著，但是14年以后，随着云计算行业的发展，业务增长量也突飞猛进，因此我们不得不推翻此前的架构，重新构建新的架构系统，当然整个过程并非想象的那么容易，所以微服务化必须自然的引进，必须要做小，做简单，然后让整个产品可以快速推进。
前面提到，Dubbo、Spring解决了大部分SOA问题，理论上讲如果Dubbo服务拆解的很干净，那么我们理应很高兴。但是问题在于，如何能在拆解之后仍旧可以保持有规范的交付却是一个不容易解决的问题。所以当中我们也采取过很多策略，比如代理服务，但是在整个微服务过程中也会产生大量成本，如何降低又是新的需要解决的问题。
图 8
图 8 是阿里内部使用语言的开发人员的人数统计图，从图中可以看出，golang的使用人数其实是相对较少的，但是其增长速度却是最快的。那么是什么原因导致gopher数量的急剧增加，大部分人都知道Java可以比作为一个静态艺人，对于很多Java开发人员来说，历史遗留包袱比较重，培养一个能在业务系统上做支持的Java人员很难，但是若只是Spring开发人员，也未必是符合我们所需。
因此我们转型GO，GO的神奇在我们在使用gRPC时的一些感悟，grpc是一个高性能的开源RTC框架，gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。
图 9
图 9 所示是Go kit与 Dubbo的一些对比，关于Go kit的更详细的内容可以在gokit.io上进行了解。
有疑问加站长微信联系（非本文作者）
