有赞云如何支持多语言

1、背景

有赞是Saas公司，向商家提供了全方位的软件服务，支撑商家进行采购、店铺、商品、营销、订单、物流等等管理服务。

在这个软件服务里，可以知足大部分的商家，为商家保驾护航。

Saas造成是追求共性的过程，Saas生态化是求同存异的过程，因此当咱们可以知足大部分客户需求时，咱们得考虑大客户的个性化需求场景。

1.1 客户分析

上面讲到咱们要求同存异，咱们要知足个性化需求，这里简单讲解一下大客户的价值，下面就不区分优点和劣势了，都放一块儿：

• 中小客户
  • 企业规模小，付费能力相对弱一些；
  • 企业周期短，没法很好的保证续费；
  • 大部分停留使用产品基本能力，说明软件可替代性强，难造成粘性；
  • 可是数量庞大；
  • 获客成本相对低一些；
• 大客户
  • 企业规模大，付费能力强；
  • 发展稳定，企业周期长，可以保证续费；
  • 有利于造成标杆案例，用于推广；
  • 只要能实现需求，对资金要求和价格不敏感；
  • 定制需求多，一旦定制，替代成本高，粘性好；

简单罗列了一下，固然其余点还有不少，对比会发现，Saas会知足大部分客户的需求，尤为是中小客户，并且中小客户量可能会达到90%以上，可是中小客户续费能力弱会致使销售成本高，同时没法造成标杆，很难有行业影响力；大客户付费能力很强，只要可以知足需求，可能不太会对相对高的价格说不，可是基本上每一个大客户都有定制需求，并且一旦达成合做，能够稳定的续费。

1.2 有赞云是干吗的

前面简单的分析了一下中小客户和大客户，因为本篇的重点在于多语言，因此就不过多的讲解，实际上一些中小客户也有定制需求，但愿本身的店铺标新立异，但愿可以用低成本而且快速知足本身的需求，当成长为大客户时再有更多的需求。

Saas传统状况下是怎么作定制的呢？

//核心业务流程
	............
    ...........
  if (店铺Id.equeals(0023423)) {
      //do custom logic
  } else if (店铺Id.equeals(0056673)) {
      //do custom logic
  } else {
      //do stardand logic
  }
	............
    ...........
复制代码

做为一个技术人员，可能会对上述代码很熟悉，客户是上帝，当客户提各类各样的需求时，若是不知足可能会致使客户远走他乡，若是去知足，那么咱们的核心业务代码耦合性会很高，并且代码扩展性不好，定制代码愈来愈多，愈来愈约束业务的发展，致使系统出现瓶颈；固然上面的代码有点直白，通常状况下会运用规则引擎、会独立一个定制应用来处理恶心的业务，可是问题依旧；更难受的一点是客户要定制页面，难道在node层作业务判断吗？看到这里相信你们都会说不，这个系统将无法扩展，业务没办法大步向前走。

这个时候有赞云出现了，因此有赞云的初衷是解决客户的个性定制需求，让各类各样的客户都可以和有赞合做，有赞提供的软件能够应用于各行各业，覆盖全部场景。

图相对抽象，可是更好理解。从图中的箭头能够看出，有赞云就是核心业务的扩展，咱们的核心业务系统将交易流程输出到有赞云，开发者或者商家能够本身定制交易流程，如卖电影票的商家能够在下单流程中加一个选座的流程；同时在流程中的各个业务关键点输出扩展能力，让开发者能够去实现这个扩展能力，如价格计算，原来价格计算是核心系统作的事情，如今开发者能够本身写价格计算逻辑，这个价格计算的结果可能就是商品的实际成交价格；前端页面组件化，开发者能够定制本身的组件，修改原有组件的行为。固然还有不少不少更加复杂的定制。

因此有赞云是一个平台，提供了定制能力，而且把定制能力市场化，开发者开发各类各样的工具型App，实现了各类奇思妙想的功能，而后发布到有赞云的应用市场；商家浏览应用市场，发现某个或者几个应用的功能和本身的需求很匹配，而后购买应用，快速又低成本的完成了本身的店铺的定制。除此以外，咱们还提供行业解决方案定制，若是你足够有能力，你能够定制整个行业的方案，好比有赞除了微信商城还有有赞教育，你能够定制一套有赞教育，这是难以想象的；大客户每每但愿可以私有定制，由于大客户的定制每每很特殊，不能推广，因此大客户找开发者能够开发自用型App，最大程度的完成本身的需求。

1.2.1 工具型应用

这里有两个角色两种资源，开发者和商家，店铺和应用。

开发者开发完App上架应用市场，商家购买应用，购买后会产生商家店铺和应用的受权关系，此时店铺可使用应用的功能，好比某应用实现了国际地址，那么该店铺的买家在下单过程当中选择地址时能够选择全球地址了。

1.2.2 自用型应用

自用型顾名思义是本身使用的，此时商家能够本身找开发者为本身开发一个应用来实现本身店铺的定制，该应用的全部权也属于商家。

1.2.3 行业解决方案

这是一整套方案，前面提到，你能够开发一个行业的软件，好比打车、外卖等等，和工具型应用同样须要上架应用市场，而后商家购买。

1.2.4 有赞云的影响

将会全面助力商家成功，大大提高商家成功发展，给商家更多可能性；

给开发者提供平台，拓展开发者的收入，提高开发能力，拓展影响力。

2、什么是多语言

2.1 应用

什么是多语言，多语言应用在什么地方，离不开一个载体，那就是应用。

应用是开发者开发定制功能的实体，它包含代码、控制台、组件（mysql、redis等等）、权限、业务配置等等。

同时这个应用是部署在有赞云提供的容器里。

那么为何要部署在有赞云提供的容器里：

1. 若是部署在私有机房和外部的云，很难保证公网的稳定和延时；
2. 咱们须要保证应用的质量，防止违规违法现象出现；
3. 部署在有赞云的容器里，和有赞核心应用更近，能够经过RPC的方式进行调用；
4. 这种方式能够监控整个链路，出问题容易排查；
5. 可靠性、稳定性、安全性有保障，这是对商家的保障。

2.2 多语言

咱们但愿经过这种模式造成一种生态，支持各类语言进行开发的开发者，因此咱们也上线了开发者社区，方便开发者学习、交流、更好地与有赞云沟通、与商家沟通。

多语言，此语言非彼语言，不是国家化支持多个国家语言的意思哈。

多语言是指咱们提供一些规范、协议、框架、基础设施等等来支持开发者进行如Java、Php、Python、NodeJs等等语言的应用开发，而且咱们的调用。

如上图所示，多语言包含不少模块，会着重挑几块讲一下，事实上每一块内容均可以写好几篇文章。

3、如何实现多语言

如何实现多语言，这是一个好问题，也是一个难题，至少作有赞云是如此，这是一个全新的模式，虽然多语言调用有多种解决方案，可是对于有赞云这种模式来讲没有前路可参考。

一开始可能还不知道如何上手，思惟导图是个很好的工具，可以帮助梳理多语言该作哪些事情，如上图所示，固然下面细分的内容还有不少。

3.1 远程调用

咱们先来看远程调用，毕竟这个是主链路，没有这个能力，咱们的扩展能力就没法实现。

相信大部分Java开发同窗都在用dubbo或者spring cloud体系，可是这些目前基本可以解决Java应用之间的RPC调用，做为一个公司来讲，咱们能够去限定你们统一用某些技术栈，统一模型。可是有赞云的用户是开发者，在有赞云里部署的应用是各个语言开发的。

3.1.1 技术选型

首先咱们须要保证远程调用时低延时的，支持多种开发语言，开发者不用感知服务的注册、发现；须要用监控和链路追踪能力；有赞云须要在开发者不感知或者不影响开发者实际开发体验的状况下去添加功能、完善链路并持续升级。

Service Mesh的理念很是符合咱们的场景，接下来看看咱们的多语言实践。

3.1.2 内部RPC

相信大部分公司的RPC框架使用了Dubbo，在Dubbo的基础上进行二次开发来知足本身公司的场景，有赞也是如此。

这张图相信你们都很熟悉，有consumer、provider、registry、monitor，可是这里有几个问题：

1. Consumer和Provider须要Java应用；
2. Consumer和Provider的行为耦合在业务应用里；
3. 架构上对跨机房、跨网络的调用没作支持。

有赞公司内部对Dubbo进行了二次开发来支持前面提到的几个问题，对于Java应用来讲，基本上和图中的架构相似。因此能够理解为有赞本来Java应用之间经过Dubbo来作RPC（这是现状），而后如今要实现跨网络而且调用多种语言的应用（目标）。

固然有赞内部自己就演进过对特定语言的调用方案。

3.1.3 部署架构

如图，有赞内部核心域和有赞开发者定制域属于两个独立的网络，两个网络之间不能进行相互访问。

上图中的Side Car是彻底由有赞自主研发的组件，取名叫Tether，他完成了服务的请求转发，与有赞监控、日志对接，实现了对服务化调用的监控和报警，并将服务发现、负载均衡、后端服务的优雅下线等等，所有都下沉到Tether层处理，因此能够理解为Tether就是Service Mesh中的Side Car。

3.1.3 Mesh实践

从上图中会发现，咱们在核心域调用App的过程当中没有采用Dubbo直连的方式进行RPC行为，而是经过了Side car进行转发。

Service Mesh架构图，若是将前面的部署架构图两边的网络域换成两个服务器，会发现和Service Mesh图相似。

Service Mesh的理念是将服务的注册、发现、服务治理、服务调用等等能力做为基础设施，让应用不用去感知业务逻辑以外的内容，这也是云原生的一部分。

由于若是让应用去作这些事情，不少事情变得不可控，好比服务协议版本不一致、出现Bug时不能统一升级。而如今有赞云的这种微服务化的架构，仅需静默升级Sidecar便可，无需任何业务开发者的参与和协同，极大的提高了总体架构的灵活性和功能迭代可控性。

前面提到，目前有赞核心域使用的Dubbo RPC协议与Java语言特性耦合严重，不适合于跨语言调用的场景。基于此，有赞云定制域中，咱们设计了基于HTTP1.1和HTTP/2协议的可拓展的RPC协议，用于跨语言调用的场景。其中HTTP/2协议因为其标准化、异步性、高性能、语义清晰等特性。

3.1.4 调用流程

讲了这么多，给你们一个比较清晰的调用流程图来理解一下。

举个例子，好比开发者实现了一个价格计算扩展点，当咱们的核心业务逻辑进行到计算价格时：

1. 价格中心经过Dubbo调用Bep（扩展点网关），这样作的好处时内部应用自己使用Dubbo框架，无须改造，就按正常Dubbo服务处理就行；
2. Bep直连Side car，当Bep收到请求后进行协议转换，而后调用Side Car；
   • 若是对方应用是Java应用，那么仍是按照原有的Dubbo协议进行调用，前文提到过，有赞内部已经作了一些Dubbo支持开发，这套方案早就存在，因此这是最低成本，对于Java开发者来讲也是很是熟悉Dubbo，这种方式对于有赞和开发者来讲比较合适。
   • 若是对方应用不是Java应用，Bep会将Dubbo协议转换为Http协议调用Side Car。
3. Side Car经过网络规则调用到有赞云开发者定制域机房的Side Car，这里有个问题，有赞云定制域机房的Side Car如何知道该调用那个App呢？
   • 首先定制域里是一个K8S的集群，当App发布的时候，经过K8S提供的能力进行服务注册；
   • 有赞云引入了Istio的Pilot，并进行了必定的改造来进行容器中应用的服务发现；
   • 还有一点就是前文提到，App和店铺之间有受权关系才能调用，因此当核心域发起Dubbo请求时系统知道是哪一个店铺的操做，知道了店铺就知道是哪一个App。

因此咱们提供的多语言方案并非一刀切，而是因地制宜，根据实际状况去作RPC的多语言方案，针对Java应用，咱们使用有赞已有的技术能力放到有赞云中来实施；对于其余类型的应用，咱们提供通用的Http1.1/2.0来拓展RPC协议，其中HTTP/2协议因为其标准化、异步性、高性能、语义清晰等特性可以知足咱们的场景。

3.1.5 RPC监控

传统Dubbo监控通常会在应用依赖的Jar包里去作数据上报，也就是应用来上报监控数据，在作多语言时这样会有一些问题：

1. 每种语言框架都得去作上报，当上报协议发生变化时就得去更新各个框架，而且推进应用去升级；
2. 应用自己作数据上报，若是这个逻辑出现问题，可能致使业务出错，应用异常；
3. 框架层会占用太多应用资源；
4. 多种语言得适配；
5. 监控会随着业务的发展，底层系统的升级，常常性的变动。

针对这几个问题，咱们将Tracing、Metrics、Logging能力下层到Side Car，屏蔽多语言，经过这种方式，咱们可让开发者无感知的去升级底层能力，升级监控；应用层只须要关注服务实现；当一种新的语言加入时，咱们的监控收集不须要作任何改造。

3.2 应用框架

讲了远程调用，那么应用如何去实现服务呢？咱们但愿给开发者提供极致的开发体验，而不是让开发者去感知太多协议层的内容，若是无论这些咱们彻底能够在有赞云文档中说明咱们的协议细节，而后让开发者去理解协议去实现协议，可是这样体验太差了，可能开发了好几天还在调试协议，而没有进入可以真正产生价值的业务代码，这是彻底不必浪费的时间。

这就须要有个应用框架来屏蔽这个麻烦。

3.2.1 扩展点调用

无论是Java语言仍是Php或者其余语言，有赞云都会提供应用框架，可是在设计之初这是一个艰难的抉择，提供应用框架意味着咱们的成本会很高，开发成本和维护成本，可是咱们开发的协议咱们本身最清楚，出现问题有赞云的开发同窗也最了解，从长期来看对于有赞云和开发者来讲都是很是有益了，尤为是对于开发者，大大下降了开发者的开发成本以及和有赞云技术支持的沟通成本。

从上图能够看到，当Side Car调用应用时，框架层会解析协议，将协议还原，经过必要的一些校验，转换为当前语言可读的对象或者实体，经过规则路由调用到具体的扩展点实现。

一目了然，开发者就关注扩展点实现就行，在扩展点实现上，针对各个语言设计了各个语言的方式来进行声明和实现，好比Java须要采用注解、Php采用Facade等等。

3.2.2 日志

对于全部语言来讲，日志是开发和运行过程当中最须要的组件，日志是一个相对稳定的组件，通过这么多年的发展，已经很明确的可以定义日志内容包含哪些信息，同时日志也是应用主动调用去打印的过程，因此咱们将日志上报能力封装在了框架里，由于他离业务更近。

天网，有赞云应用的日志平台，全部开发者的应用日志都会打印上传到天网进行计算和存储；

因此针对日志，天网提供了统一的日志协议和端口，应用只须要按照规范封装日志格式，就能够将日志打印到天网，应用的日志并非存在在服务器本地文件上；

3.2.2.1 Java应用

import org.slf4j.Logger;
  import org.slf4j.LoggerFactory;
  
  ...........................
    ..............................
        private static final Logger logger = LoggerFactory.getLogger(Xxxxx.class);
  ............................
    ...............................
    		logger.info("test log");
复制代码

在应用框架层，已经封装好了日志协议和上报天网的逻辑，开发者只须要像日常使用Slf4j同样打印日志就行。

那么在实现上咱们使用了Slf4j的规范，经过SPI实现了天网的日志管道。

3.2.2.2 Php应用

Php框架使用Monolog，在Monolog里增长了日志处理器SkynetProcessor来封装日志协议，经过SocketHandler来打印日志到Rsyslog上。

3.3 其余

回到一开始多语言的思惟导图，要支持多语言，其实要作不少事情。

咱们在作这些事情的原则就是尽可能让开发者少感知，保证总体系统的健壮性和扩展能力。

在作这些事情时最麻烦的可能就是升级，当咱们发布一个新功能或者升级了协议后，推进全部应用去升级是一个漫长的周期，此时咱们的底层可能得作无数的兼容逻辑，这样会致使系统没法往前发展，同时开发者也会很反感，频繁的去手动指定版本并去发布（此时没有修改一行业务代码、并且可能还得改造代码）。

关注其余的一些模块，本期暂时就先略过了。

4、规划与展望

规划的目标是但愿提高开发者的体验，助力商家成功。

因此会开放更多扩展能力，真正作到全流程每一个细节点均可以定制。

在开发体验上，须要实现WebIDE，方便开发调试，甚至让开发者不用感知项目，Faas也多是一条很好的路。

在多语言上，尽可能得作到统一底层，而不是新增一种语言给咱们带来浩大的工做量。

同时乐见各路开发者的奇思妙想，开发出各类很是有意思、有价值的应用。基于此，有赞云在6月5日上线了有赞云开发者大赛，面向全国发出"英雄帖"，一个优质应用可奖励40万，欢迎你们报名参加。www.youzanyun.com/contest