转载

微服务框架的基本学习

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
  微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。

通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。

如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

关于 Service-Center 的介绍

Service-Center（SC）是一个服务注册中心。服务提供者（provider）可以将自身的实例信息注册到 SC，以供服务消费者（consumer）从 SC 发现并使用它。

Service-Center 设计原理

实战项目

Go 语言是微服务开发团队的一个很好的选择。即使你的项目可能不需要像谷歌那样向全世界提供电子邮件、地图、搜索和其他云服务，但仍然可能需要向用户提供数十种不同的小型信息服务。值得一提的是，Docker 是用 Go 语言开发的。

ServiceComb 的基本介绍

ServiceComb是一个微服务框架，它能够帮助企业快速构建云原生应用，通过一系列解决方案帮助用户快速开发微服务应用的同时实现对这些微服务应用的高效运维管理。ServiceComb本身有强大的技术背景和团队，它源于华为云CSE微服务引擎（Cloud Service Engine）平台。

目前CSE的Java开发包和Golang开发包都已经在ServiceComb项目中开源，Java 开发包部分已进入Apache软件基金会孵化，Golang开发包部分也在不断开发完善中，不久也将启动Apache软件基金会捐赠流程。

ServiceComb主要包含的是Java底座（Chassis），整个语言开发包包含服务契约、编程模型、运行模型与通信模型四个部分。

Chassis是Chris Richardson提出一种微服务模式，它可以使用户在构建微服务的过程中，只聚焦于业务逻辑本身，而不需要去处理日志、外部配置、分布式追踪等环节，Chassis将这些环节交给专门的框架来处理。

服务契约： ServiceComb通过服务契约支持Java、Go语言底座开发的服务可以相互访问。服务契约是建立在OpenAPI基础之上的，OpenAPI规范是Linux基金会的一个项目，通过定义一种用来描述API格式或API定义的语言，来规范RESTful服务开发。Open API提供了一套比较完整的开发工具链，在服务契约的基础上我们可以自动生成服务文档，服务调用开发包以及服务调用测试代码。

编程模型： Java语言底座支持多种RESTful服务的编程方式，即支持应用广泛的Spring MVC与JAXRS编程模型，也支持POJO + 服务契约的开发方式来描述RESTful服务。由于在Java Chassis先将这些编程模型转换成为服务契约Swagger对象，然后交由内部运行模型以及通信模型进行处理，所以Java Chassis并不依赖Spring MVC以及JAXRS的底层实现。目前Go Chassis和Java Chassis支持RESTful级别的互联互通。

运行模型：大家在开发应用的过程中，会有很多服务扩展的需求，例如根据用户身份认证信息，对服务调用进行认证。Chassis架构支持在运行时通过配置处理链（handler）的方式来进行服务扩展。ServiceComb缺省提供服务发现、容错熔断以及调用链追踪等处理链。用户可以通过配置文件的方式，在应用启动的时候加载对应的处理链。

通信模型：语言底座通过通信模型对外进行交互，其中包含了消息序列化和反序列化的模块以及底层传输的模块。值得一提的 Java Chassis的通信模型是建立在Vertx基础之上了，内部已经完全异步化了，微服务在全异步工作模式下有很高的性能。

ServiceComb的特点：