随笔分类 - 架构及扩展
摘要：眼下，做互联网应用，最火的架构是微服务，最热的研发管理就是DevOps， 没有之一。微服务、DevOps已经被大量应用，它们已经像传说中的那样，可以无所不能。特来电云平台，通过近两年多的实践，发现完全不像大家说的那样简单，大家是报喜不报忧，实在是水太深，谁做谁知道。今天就与大家分享一下在微服务架构+
阅读全文
摘要：做互联网应用很重要的一点是要保证服务可用性，特别是某些业务更是需要7*24小时不间断的对外提供服务，任何停机、宕机都会引起大面积的用户不满。持续可用性是把业务服务化时一个需要考虑的重要指标，很多时候我们都会牺牲一些功能来换取可用性。如何保证服务的持续可用性，是每个互联网架构师一直坚持不懈追求的目标。
阅读全文
摘要：第一种是集中式LB方案，如下图，在服务消费者和服务提供者之间有一个独立的LB，LB通常是专门的硬件设备如F5，或者基于软件如LVS，HAproxy等实现。LB上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向LB发起请求，由LB以某种策略（比如Round-Robin）
阅读全文
摘要：限流器用于控制在网络上发送或接收的流量速率。限流器对于大部分使用场景是十分高效的，但有时我们需要完全丢弃低优先级的请求，以确保更多关键请求的处理，这称为负载降级（load shedder）。负载降级可以根据系统的整体状态而不是正在请求的用户来进行决策。它可以帮助我们应对突发事件，确保核心部分正常工作
阅读全文
摘要：将单体应用迁移到分布式框架后，很大可能会遇到这样的问题：系统仅有一个控制单元，它会调用多个运算单元，如果某个运算单元（作为服务提供者）不可用，将导致控制单元（作为服务调用者）被阻塞，最终导致控制单元崩溃，进而导致整个系统都面临着瘫痪的风险。 服务化后面临的挑战： 服务管理：敏捷迭代后的微服务可能越来
阅读全文
摘要：我们的系统大多拆分为分布式SOA，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful，既然是通信，那么就有可能再服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有
阅读全文
摘要：特来电云平台从创立到现在已有2年多时间，总结来说，我们主要有2个阶段的发展： 1.2015年是云平台发展的元年，在这一年我们快速搭建了充电系统，因为公司成立不久，我们没有专业的公共技术团队，在技术架构上做的不好。在1.0研发的过程中,我们也意识到了这个问题的严重性，所以在15年下半年组建公共技术团队
阅读全文
摘要：1. 单一职责原则 1. 一个类只有一个职责，不应既做这又做那，这样的好处是： 2. 降低了类的复杂性 3. 提高了代码的可读性，可维护性 4. 降低了因变更带来的风险2. 里氏替换原则 1. 一个子类必须实现父类的所有方法 2. 一个子类可以拥有父类没有的方法 3. 在所有需要父类对象的地方都可以
阅读全文
摘要：从传统软件公司跑出来已经一年有余，10多年的基础平台研发和知识积累，让转型互联网架构和开发感觉没想象中的难，可能是逼格太低，亦或者公司的业务量还没到爆发的时间。但是不管怎么说，能有一次从头搭建互联网应用的机会是可遇不可求的。多少人挤破了头跳槽BAT，而偶却不羡慕。不管结果如何，先结合公司业务和互联网
阅读全文