云服务器内容精选

  • 为什么一定要定义服务契约? 企业级系统规模普遍较大,微服务组件众多,所以对服务间接口进行统一管理是企业的关键需求。微服务引擎通过契约管理满足这一需求。 管理角度:通过契约管理,企业中的接口管理者可以统一定义微服务的契约文件(符合接口描述标准的接口定义文件),从而做到规范并协调多个开发团队的接口开发,降低沟通成本且避免后期的混乱。 开发角度:在微服务开发的时候,不同团队甚至不同ISV间,可以基于统一的契约文件开发同一应用或系统,从而方便整体系统一致性的维护。具体表现在,单体应用中模间是代码级调用,在编译期就可以解决API不兼容问题,修复成本也极低。微服务解耦后,服务间变为了远程调用,接口不一致通常发现时间较晚,会造成更大的修复成本。有了契约可以保证架构师设计契约,严格审查变更,并反向生成代码,保证兼容性。 另外,对于规模较小、统一管理要求不高的系统,产品支持从接口代码自动生成契约文件。 父主题: 应用开发问题
  • 微服务和普通应用有什么不同? 微服务是一种架构模式,其核心是将一个单体应用分成多个部分进行开发。所以微服务架构的应用程序,其本质上是一个分布式应用。 基于微服务架构构建的应用程序,可以让业务变化更快,整体系统可靠性更高。 类型 微服务 普通应用 开发 每个微服务的体量相对较小,业界的two pizza团队和“2周即可全部重写全部代码”等都可以作为微服务划分的参考。在开发时期,需注意服务接口的定义以与周边微服务进行配合,“基于契约”的开发方式是非常推荐的。 微服务开发,请参考开发微服务应用。 普通应用逻辑复杂、模块耦合、代码臃肿、修改难度大、版本迭代效率低下。 部署 微服务组成的应用系统通常比较复杂,在一次性部署的时候,需要进行编排部署。 微服务应用部署,请参考创建并部署组件。 普通应用可能会比较大,构建和部署时间也相应地比较长,不利于频繁部署,阻碍持续交付。在移动应用开发中,这个问题会显得尤为严重。 运维 在原来的指标监控、日志收集之外还非常强调治理。其核心理念是在运行时期通过对线上系统的各种调整以达到系统整体健康度要求的效果。 应用运维,请参考组件运维。 普通应用线上问题修复周期长,任何一个线上问题修复都需要对整个应用系统进行全面升级。 父主题: 应用开发问题
  • 解决方法 可在开发环境下使用mvn dependency:tree命令查看依赖树,排查微服务开发框架同netty版本是否匹配。 例如,ServiceComb 2.0.1开发框架所匹配的netty依赖版本为4.1.45.Final。 使用maven管理复杂依赖关系,请参考:https://servicecomb.apache.org/cn/docs/maven_dependency_management/。