Edwin & Xinyu's Blog  

查无此人,查有此地

聊聊架构那些事(一) 有更新!

前阵子有朋友跟我反映先前写的《Java基础之GC那些事》太过涉及基础和底层,不利于(PPT)架构师能力发展。今天换换口味,聊下架构。

回想刚学编程那阵子,所做的Web系统,模式无非是简单的应用服务,文件服务外加数据库。不管是CS架构还是BS架构,基本都逃不出这个模式。那时候的视角,仅限于应用程序功能本身,对系统架构没有进一步的认识。

“学生做的项目是只能看不能用的”,从现在来看,虽然绝对了点,但也有几分道理。上图架构随着时间推移,问题逐步产生:
  • 用户量增加,应用服务器性能出现瓶颈。

  • 应用服务文件服务和数据库由于均是单实例部署,一处出现故障便会导致应用不可用,是为单点故障。

  • 应用程序频繁访问数据库,数据库性能出现瓶颈。

    于是2.0架构出现了。

运行多台应用服务器改善应用服务器的性能瓶颈,并通过负载均衡统一转发。增加本地缓存减缓数据库服务次数。通过文件服务器和数据库服务器的各自Active-Standby方案避免单点故障。问题似乎轻易解决了?熟知当引入一个新变量解决现有问题时定会产生第二个问题。

 负载均衡转发请求策略是怎么样的?
  • 如果是均衡策略(如Round Robin)意味着用户每次请求不一定会在同一台服务器上进行处理,那么服务器怎么辨识用户身份?总不能每次再额外增加数据库压力。同时如果本地缓存存放了用户信息,则缓存的命中率也堪忧。要知道,如果缓存命中率不高,访问缓存就不如直接访问数据库了。

  • 如果是粘连策略(即同一session请求优先转发给同一服务器)意味着应用服务器的负载不再均衡,随着压力的增加,个别服务器可能出现过载,个别服务器出现饥饿的情况。同时,如果用户状态保留在服务器上,如果服务器出现不可用而前方交换机将请求漂移至其他可用服务器,由于该服务器没有存放用户信息,必然导致该用户应用不可用。

  • 即使解决了上述问题,如果用户量的进一步增加,瓶颈还是出现了:文件和数据库由于是Active-Standby模式,扩容无法scale out(横向服务升级,通过增加服务节点数量来提升处理能力) ,只能进行scale up(纵向服务器升级,即改善服务器配置来提升服务处理能力),而scale up不但有瓶颈而且代价高昂。

于是3.0架构出现了。

 引入分布式缓存服务(scale out )用于存放应用缓存信息;引入分布式文件服务(scale out ) 用于存放应用文件 信息;引入分布式数据库服务(scale out ) 用于存放应用数据库信息。

 可是这引发了著名的CAP问题:**在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼**。若服务本身是分布式的的(即满足P),则势必无法同时满足一致性(C)或是可用性(A)。
  • 试想应用访问分布式服务节点A,写入数据X成功,如果要保证高一致性(即这时其他请求访问其他节点如B/C也能正确读到数据X),势必需要降低该分布式服务可用性(即在A上写完X后要等B/C完全写完才被认为写成功)。

  • 同样,如果要保证高可用性,写入X后立即反馈,这时万一有其他请求访问其他节点如B/C是不能保证正确读到X的。

  • 分布式服务需要有一定冗余度,即出现少数服务实例不可用不会引起整体服务不可用。

    本质上,分布式问题可以通过一系列分布式算法进行规避和解决。比如数据存几份怎么存的问题,可以通过一致性Hash算法进行Hash环抽象。比如节点状态同步的问题,通过Zab/Raft这类一致性协议解决。当然如果你是你喜欢根本的paxos协议,那只能说你是大牛。

 再然后,随着业务成熟度的提升,同质化业务服务的需求逐步增多。怎么在保持高扩展性的同时进行尽可能的服务复用?

 于是4.0架构出现了。

 应用以(微)服务方式进行拆分,并通过服务目录进行注册。这样,应用和应用,服务和服务之间可以通过访问服务目录获取Active的服务清单,再进行点对点去中心化访问。

 可是,新的问题又来了。怎么在保持吞吐量的同时保证数据的一致性?

 我们再回过头来看看传统的应用事务,不管是JDBC还是JTA,本质上都是XA的2PC实现。注意,一般意义上,这是一个容错的串行模型。这里容错是指保证了分布式事务的原子性:即所有结点要么全做要么全不做 。为了避免发生问题时数据出现不一致性,数据库会堵塞事务进行规避,这就一定意义上影响了应用的吞吐量。这也引入了3PC,通过写类似redo日志等方式,默认提交,解决的单点故障问题,同时减少阻塞 。当然,在业务允许的前提下,使用服务补偿模式或者Queue模式,也不外乎一个可行的方案。

 外面看看,越来越多的解决方案都似乎在follow上文4.0架构这个标准。不管业务场景是B2B还是B2C,TPS是50还是500,服务复用情况如何,一律进行微服务化。程序员嘛,总喜欢折腾。殊不知,**站在企业的立场上关心的不是微不微服务,而是用有限的投资满足业务需求,并且未来有一定演进。而这,才是架构师的职责,平衡**。根据TOGAF的理论,系统架构是架构愿景的衍生产物。使命愿景是大方向,如果这个错了,则会对后续工作造成不可想象的后果。要知道,IT本身并不能够促进企业的任何优势,它只是企业运行的必要条件,关键是IT的应用如何与企业战略,组织,流程和管理控制系统的融合 。

 所谓的融合,做起来没这么简单。要知道**业务领域的立场和IT系统平台的立场是存在较大差异的**。一般不同的业务领域由于不同的业务架构,导致会产生有不同的IT管理模式,进而产生不同的系统架构。架构的异构和缺乏共享是传统IT价值链遗失的地方。最近在研究IT4IT,4个价值链中的Detect to Correct (D2C) 也谈到这个问题,后续再进行交流。

 说了这么多,那么架构应该是从上往下做还是从下往上做呢?今天和朋友刚好探讨过这个问题。我的回答是:**架构师成长,从下往上。架构师布道,从上往下**。

validate