微服务和普通应用有什么不同？
微服务是一种架构模式，其核心是将一个单体应用分成多个部分进行开发。所以微服务架构的应用程序，其本质上是一个分布式应用。
基于微服务架构构建的应用程序，可以让业务变化更快，整体系统可靠性更高。
| 类型 | 微服务 | 普通应用 |
|---|---|---|
| 开发 | 每个微服务的体量相对较小，业界的two pizza团队和“2周即可全部重写全部代码”等都可以作为微服务划分的参考。 在开发时期，需注意服务接口的定义以与周边微服务进行配合，“基于契约”的开发方式是非常推荐的。 微服务开发，请参考“帮助中心 > 微服务云应用平台 > 开发指南 > 微服务开发指南 > 开发微服务应用”章节。 |
普通应用逻辑复杂、模块耦合、代码臃肿、修改难度大、版本迭代效率低下。 |
| 部署 | 微服务组成的应用系统通常比较复杂，在一次性部署的时候，需要进行编排部署。 微服务应用部署，请参考部署组件。 |
普通应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。 在移动应用开发中，这个问题会显得尤为严重。 |
| 运维 | 在原来的指标监控、日志收集之外还非常强调治理。 其核心理念是在运行时期通过对线上系统的各种调整以达到系统整体健康度要求的效果。 应用运维，请参考应用运维。 |
普通应用线上问题修复周期长，任何一个线上问题修复都需要对整个应用系统进行全面升级。 |
部署在云上的微服务如何进行排错？
对于问题的定界，可以使用微服务仪表盘，通过仪表盘可以看到系统内所有微服务及其实例的实时运行情况，找到没有正常工作的节点。
找到问题节点后，可以通过APM查看问题节点的应用日志来分析具体问题。
如何解决获取依赖失败的问题？
配置maven镜像源之后，获取依赖失败。
对于企业内部需要使用代理访问外网的情况，需要配置Maven代理，可以在用户目录（windows中如 C:\Users\yang **\） 下的.m2目录中setting.xml（用户配置）或Maven安装目录下的conf目录中setting.xml（系统全局配置）里配置代理来实现。
找到setting.xml文件中的标签对，在其内配置代理信息，参考如下样例。
<proxies>
<!-- proxy
| Specification for one proxy, to be used in connecting to the network.
|
-->
<proxy>
<id>自定义proxyid，多个proxy配置间不可重复</id>
<active>true</active>
<protocol>http</protocol>
<username>proxy认证帐号</username>
<password>proxy认证密码</password>
<host>企业的代理地址</host>
<port>代理地址端口号</port>
</proxy>
<proxy>
<id>自定义proxyid，多个proxy配置间不可重复</id>
<active>true</active>
<protocol>http</protocol>
<username>proxy认证帐号</username>
<password>proxy认证密码</password>
<host>企业的代理地址</host>
<port>代理地址端口号</port>
</proxy>
</proxies>
服务名重复校验范围是什么？
问题描述
服务名重复校验范围是什么？
解决方法
服务名重复校验范围是微服务名称、微服务应用、微服务版本和微服务环境。
是一个微服务的主键，标识一个唯一的微服务。
请确保主键不重复。
为什么一定要定义服务契约？
企业级系统规模普遍较大，微服务组件众多，所以对服务间接口进行统一管理是企业的关键需求。微服务引擎通过契约管理满足这一需求。
管理角度：通过契约管理，企业中的接口管理者可以统一定义微服务的契约文件（符合接口描述标准的接口定义文件），从而做到规范并协调多个开发团队的接口开发，降低沟通成本且避免后期的混乱。
开发角度：在微服务开发的时候，不同团队甚至不同ISV间，可以基于统一的契约文件开发同一应用或系统，从而方便整体系统一致性的维护。具体表现在，单体应用中模间是代码级调用，在编译期就可以解决API不兼容问题，修复成本也极低。微服务解耦后，服务间变为了远程调用，接口不一致通常发现时间较晚，会造成更大的修复成本。有了契约可以保证架构师设计契约，严格审查变更，并反向生成代码，保证兼容性。
另外，对于规模较小、统一管理要求不高的系统，产品支持从接口代码自动生成契约文件。
