WillemJiang commented on a change in pull request #71: add blog to descripe open design of ServiceComb URL: https://github.com/apache/incubator-servicecomb-website/pull/71#discussion_r184035288
########## File path: _posts/cn/2018-04-25-open-design.md ########## @@ -0,0 +1,315 @@ +--- +title: "如何设计一个优质的微服务框架：Apache ServiceComb 的开放性设计" +lang: cn +ref: open-design +permalink: /cn/docs/open-design/ +excerpt: "本文讲述了整个 开源微服务框架 Apache ServiceComb 设计形成的前因后果，尝试从理念、思想和实践结合的维度剖析一个优质的微服务框架应该具备哪些要素，包括但不限于 对开发者友好、高性能、内外部扩展性>等。" +author: Zen Lin +tags: [设计, 开放，扩展] +redirect_from: + - /theme-setup/ +--- + +【摘要】 一个优质的微服务框架需要考虑的要素众多，在满足微服务设计理念的前提下，也是一个不断实践优化的过程。 +本文讲述了整个 开源微服务框架 Apache ServiceComb 设计形成的前因后果，尝试从理念、思想和实践结合的维度剖析一个优质的微服务框架应该具备哪些要素，包括但不限于 对开发者友好、高性能、内外部扩展性等。 +阅读本文有利于加深对微服务理念和框架的理解，给予微服务用户或开发者以帮助，这也是 Apache ServiceComb 的前身华为云微服务引擎的智慧结晶，从细节处承载了华为云自身多年云化转型的经验。 + +<!-- more --> + +## 写在前面 + +[开源微服务框架 Apache ServiceComb](http://servicecomb.incubator.apache.org/cn/) 的前身为华为云的 [微服务引擎 CSE (Cloud Service Engine) 云服务](https://support.huaweicloud.com/usermanual-servicestage/zh-cn_topic_0053812706.html), ServiceComb 的早期版本和多数第一批做微服务或分布式框架先贤一样，为了追求高性能，做过非常多如 改善编码效率 和改进通信协议等尝试。然而，随着业务规模的递增，需求也逐渐呈现多样化，单方面通过传统手段追求高性能导致在面对多样化需求时遇到了各种挑战，遗留系统的通信、接入各种不同的终端、协议健壮性、防攻击等各种挑战迎面而来。 + +Apache ServiceComb，愿景是帮助企业快速构建云原生应用，通过一系列解决方案帮助用户快速开发微服务应用的同时实现对这些微服务应用的高效运维管理，保持中立性以避免厂商LockIn成为了关键任务。对于此， Apache ServiceComb 需要有友好的机制能够对接各微服务主流技术栈技术 或 开发框架。 + +在系列挑战的驱动下， Aapche ServiceComb 设计团队逐步形成了 “全面开放，使用标准协议，架构易于拆分和扩展，对开发人员友好，可以与业界其他主流框架互通集成” 的共识， 本文将着重分享这些共识是如何体现在Apache ServiceComb 的设计中的。 + +## 开放和标准 + +开放和标准应用到设计的不同的层面。一方面是连接组织和开发人员，一方面是连接异构系统。组织和开发人员的复杂性来源于技能的多样性，大家使用不同的开发语言，同一种开发语言存在多样的开发习惯；系统的多样性来源于系统之间的通信协议，为了实现与异构系统的通信，必须具备良好的适配不同通信协议的能力。 + +### 连接组织和开发人员 + +#### 编程风格 + +每位技术人员都或多或少拥有自己的 Coding 习惯或爱好的技术， 使用个人熟练的方式从事技术工作往往更加高效和舒适。 + +[开源微服务框架 Apache ServiceComb](http://servicecomb.incubator.apache.org/cn/) 的早期版本实现了 gRPC 协议，然而在项目演进过程中我们发现大量技术人员并不熟悉书写 IDL ， 对 IDL 具体支持哪些特性也不清楚。 大多数情况下，用户每碰到一个场景就需要翻开协议规范看一遍， 而 IDL 缺少配套的编辑或语法检查等工具也导致了开发效率的降低。 + +于是 Apache ServiceComb 设计团队开始思考是否有方法能够在确保保持用户开发习惯的前提下支持 gRPC 。 + +设计团队结合自己的 Java 编程史，分析当下主流框架，并听取社区用户的反馈找到了一些共性： + +- 使用 RPC 方式描述对外接口。gRPC 、Corba 、WebService 等技术人员谙于此道。 +- 使用 JAX-RS 或 Spring MVC 风格开发 REST 接口。REST 风格开发随着微服务架构兴起，JAX-RS 和 Spring MVC 已然成为 Java REST 的开发事实标准， Spring 的拥抱者都比较熟悉。 + +Apache ServiceComb 很快在社区设计层面达成了一致，通过缺省支持以上共性来拥抱90%的开发者， 让大多数的 Java 开发者们能够快速开始工作。 + +除以上共识外，Apache ServiceComb 还额外做了进一步的优化，以保证不同编程风格的兼容性，使用户或开发者倍感灵活及舒适。 + +在下面的例子中，展示了 Provider和Consumer 代码的各种实现，在同一个微服务中，这些编程方式可以同时出现；同一段 Consumer 代码中可以访问各种不同的编程风格的 Provider 实现。 + +**RPC 方式的 Provider** + +```java +@RpcSchema(schemaId="hello") +publicclassHelloImplimplementsHello{ Review comment: All the spaces were trimmed, we need to fix it. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
