微服务浅述---架构演进

Posted 2021-02-03 frankltf

微服务浅述---架构演进

• 
• 提到架构演进，我们很容易想到‘单体应用---分布式/SOA---微服务’的演进过程，那么为什么会有这个必然演进？演进的过程中遇到了哪些坑？是怎么解决这些坑的？
• 为什么会有这个必然的架构演进？
  • 因为痛点驱动。因为互联网公司很容易突然爆发，今年的数据量可能比去年的数据量翻上N倍。那么刚开始的时候公司用的是单体架构，即一个业务逻辑一撸到底。比如电商公司，从前端商品展示，购物车，下单，订单生成，发货，物流等等这些业务逻辑
    全部写在一个工程内，数据放在一个库内，部署在一个服务器上。
  • 随着业务的增长，系统的数据量大增，慢慢的单体应用就暴露出很多问题。
    • 从开发角度来说，对某个业务逻辑进行修改的时候，痛苦至极，因为有可能只是修改一个参数，就要梳理清楚一大块的业务逻辑，然后要理清楚这些涉及业务逻辑的所有代码，运气不好的，会遇到几千行的一个函数，修改完后，要自测，那就要对整个流程进行自测。如果没改好，上线后就有可能导致主流程瘫痪的事故，痛苦至极。
    • 从测试角度来讲，只要某个需求改动，就要对涉及这块业务的所有业务进行测试，因为谁也不能百分百确保，这个需求不影响其他正常流程。
    • 从数据库角度来说，数据的增加，库和表都会增大，那总是会到某个阈值后，整个系统的性能都会大大降低。且不可持续，数据还在增加，单库单表的承受能力肯定是有限的。
    • 从运维角度来说，服务器的各项指标都高居不下。有的业务模块数据量大，有的小，但是控制手段少，很是担心在某个时间点，服务器和数据库都超过他们的承受能力崩溃掉。
    • 这个阶段，一般数据量在百万或者千万出头。用户体验卡顿，线上bug不断。这个阶段单体架构的问题都暴露出来了。
    • 从管理角度来说，系统增大，团队也肯定随着增大，那么对于团队的分工和配合就有很多问题。
    • 上边这个问题，也许可以通过分库分表，优化代码结构等方式来一定程度上缓解上边问题，但是不能从根本上解决问题。
• 那么如何解决上边单体架构的问题呢？那么就是分布式。
  • 如何拆分呢？很容易就想到按照业务逻辑进行垂直拆分，将业务分成各个业务模块，每个业务模块独立出去成为单独的系统。即将ERP系统拆分，拆分出来前端网站，用户系统，订单系统，库存系统等等。每个系统都有自己的服务器、数据库、团队等等。
• 分布式下每个系统还是会随着数据和业务的增长而继续膨胀，那么就要继续拆分，并且每个系统之间会有相同的服务进行抽离，这样就慢慢地演变成面向服务的SOA架构。
  • 但是就是SOA架构，它的服务粒度还是很粗。需要对服务进行更深一步的拆分，这就演进到了微服务架构。
• 微服务
  • 首先第一个问题就是服务如何拆分？有没有什么理论指导？
    • 这就要参考康威定律和领域驱动设计。
  • 那么首先要解决的问题是各个系统之间如何通信？
    • 常用的方式有rpc，http,mq消息中间件等等
  • 系统被拆分成众多服务之后，服务之间会产生各种调用，那么如何管理这些服务？ 有的服务要做集群，那么如何做负载均衡？有的服务挂掉了如何处理？等等这些问题。这就是所谓的服务治理。服务治理这个概念并不是解决某一个问题，而是解决一堆问题就是服务治理。
  • 首先是第一个问题，服务之间会产生各种调用，那么就要在各个服务之中配置它要调用服务的地址信息，一旦一个服务的地址有改动，就要改所有配置了这个服务信息的其它服务，这显然是不行的，这个时候就需要一个注册中心，来管理所有服务的地址信息，服务生产者可以提供服务后，第一步先来注册中心注册，服务消费者需要什么服务可以来注册中心获取对应服务信息，然后再去请求需要的服务。服务中心主要是对内的。
  • 不同的微服务聚合成各种聚合服务之后，需要暴露给客户端去调用，而且要监控各个服务的调用情况，那么这个时候就需要一个网关系统，它的主要功能就是根据客户端的请求url解析后，将其分发到不同的目标服务。就是API网关主要是控制外部对内的访问。
    • 
  • 一般大公司是不会暴露公司服务内部的真实ip的，那么就要做反向代理，通过反向代理来隐藏公司的真实ip。
  • 被拆分的服务肯定被调用的频次是不一样的，有的服务就必须做集群，通过多台服务器内跑相同的某个服务，来提高某个服务吞吐能力，
  • 在集群场景下，那么多个服务器之间如何控制？ 这就是所谓的负载均衡问题。
  • 在集群场景下，有的服务是会产生状态的，比如产生session，那么如何解决集群中的session一致性问题？
  • 如果在某种情况下，某个服务的服务器挂掉了，不能提供服务了，那么调用它的那个服务也可能挂掉，这样就会产生服务的雪崩效应。
  • 那么如何解决雪崩效应呢？那么就要对各个服务节点做一主一备或者一主多备，万一某个服务的服务器挂掉了，备用服务就应马上接替主服务器的位置，提供服务，同事相应的机制去马上重启主服务器，如果主服务器重启成功，又可以对外提供服务，那么就重新回到主服务器的位置，提供服务，否则通知运维人员去检查问题。这就是所谓的高可用。
  • 在双十一等场景下，流量会产生很多倍的暴增，那么一般是不能做到百分百保证自己的系统是可以完全保证所有对外服务都可以正常提供的，那么这个场景下就要做一下取舍，万一出现这种情况，就要对于某些不重要的服务停掉，从而保证业务的主流程不受影响。如果流量下降，就又可以开放那些被停掉的次要服务，重新对外提供服务，这就是所谓的服务降级、限流。
  • 系统被拆分成众多服务之后，有些服务之间虽然是不同业务模块的，但它们从业务角度来将是同一个事务，即一个服务成功，那么其他服务也必须有结果，
    不能产生一个服务有结果后，其他服务没有执行，那么这就是所谓的分布式事务问题。
  • 在某个场景下，可以会发生众多服务同时要消耗一个资源，或者集群环境下，同一个服务的多个进程同事消耗一个资源，无论是多个服务还是集群，他们都分布在不同的服务器内，这就是高并发问题。
  • 如何解决上边的高并发问题？单体应用中，解决并发问题是用的锁，那么分布式场景下，就要通过分布式锁来解决上述问题。
  • 微服务架构下，服务的粒度都非常小，不可能让一个服务占用一个服务器，这样太浪费，大多数情况下，一个服务器的性能完全可以满足多个服务的运行，那么如何让多个服务在同一个服务器内运行呢？ 就是通过容器技术，这就是所谓的容器。
  • 假如客户端某次调用后发生问题，需要定位问题，但是一个服务内部可以调用了其它服务，其它服务又调用了其它服务，那么如何监控这些服务呢的调用呢？
    这就是服务追踪问题，而解决的技术就是链路监控技术。
  • 一般情况下，公司开始想微服务架构改造时，要保证现有系统能正常对外提供服务，考虑到现有团队的技术储备等等，必然会用到不同的语言来进行微服务改造，这就是所谓的异构架构。