华为云微服务架构学习笔记
微服务引言
微服务出现的动机,现在业务变革太快了,要求技术架构需要跟上变化,
从单体架构到soa架构到微服务架构,灵活性,轻快做了进一步演进,从互联网公司到企业级的应用CRM系统,金融系统
不仅仅是应用的架构,自组织团队,完成分析开发测试部署运维,7~8个人;技术实践;流程与工具
Serverless(微服务),Martin Flower(发明人),独立部署,独立演进,允许技术多样性,模块化边界性
原来只需要运维一个应用,现在需要应用多个
原来单体调用(在进程内),现在要远程调用,慢,可靠性
单体应用用数据库的事务保持一致性,但是微服务有多个数据库,可以多实例连接一个数据库,用最合适的数据库技术,原来是关系型数据库,EJB强事务,但现在有些用redis和mongDB非关系型数据库,保持数据的一致性
微服务架构解决方案
华为云微服务产品,微服务引擎CSE微服务引擎
降级,访问剧增的时候把一些服务关闭,页面上也不会显示相关的内容
灰度发布:有两个版本,一个是1.0版本,一个而是2.0版本,2.0版本的筛选条件设置为成都,即在搜索别的城市,eg广州的时候
选择1.0版本,搜索成都的时候选择2.0版本.
微服务治理之负载均衡,分发到多个服务器,提供响应反应快的实例,提供最快的告诉
微服务治理之限流,超过限流请求量,防止故障蔓延
微服务治理之熔断,可能有级联故障,有因服务者不可用导致"调用服务者不可用"的问题,当窗口请求数超过20,或者失败率超过60%之后,熔断5000ms后再次恢复
微服务治理之容错,提供四种容错机制,出现异常以后的策略failover:失败后自动切换,在其他机器上进行测试;Failfast:失败后立即返回结果,不重试
Failback:失败后在同一个服务器上重试;custom:自定义;
CES开源版本ServiceComb
ServiceComb基于华为内部的CSE(Cloud Service Engine)框架开源而来，这个框架在华为内部已经存在了2年多，支撑了多个大型的商业项目。有相对传统的企业级项目，也有类似手机应用这样的互联网属性比较强的项目。并且在成为整个华为公司统一的微服务标准框架后，依然有越来越多的产品在逐渐使用它开发自己的微服务。
“不用SpringBoot的原因”，这个问题本身就有问题，因为ServiceComb并不阻碍你用SpringBoot，也不阻碍你用SpringCloud。如果你用这两个技术，可以把ServiceComb当做封装好了的几个starter，可以让你更方便地构建你的应用，就像楼主同学所说，在ServiceComb里面对Netflix OSS的一些组件做了很深度的集成和封装，不像SpringCloud这样一个大杂烩，在ServiceComb里面从头到尾进行了封装。你可以把它想象成是提供了类似Fegin的标记式开发方式，提供了SpringMVC的开发方式，提供了JAXRS的开发方式，然后对于你来说，这就够了，因为你用了这些开发方式开发了代码以后，LB、Hystrix已经被封装在后面了，你不用自己再去构建Command来用Hystrix。当然，如果你想自己扩展也可以。但是你也真的可以不用SpringBoot而只用ServiceComb。原因么，内部产品太多，各个团队水平和情况各不相同，有的就是不愿意用SpringBoot我们也没办法。动不动就说影响了他们几个亿的大买卖我们也很无奈啊。所以其实ServiceComb的第一个内部版本我们是依赖SpringBoot的，但是后面逐渐优化逐渐瘦身，开出来的版本已经不再强依赖SpringBoot了（注意，不依赖不表示不能一起用）。
对于Dubbo，微服务不是说好了“各个微服务用最适合的语言写不能绑定语言”吗？不是说好的“每个进程是一个微服务”吗？所以我们认为它是一个非常优秀的SOA时代的RPC框架，但是就微服务而言，它还有一些问题。
微服务全生命周期管理
微服务开发生命管理,放大优势,减小复杂度
微服务运维生命管理:devops,通过治理