后端架构学习

1. 什么是后端服务的架构？怎么去理解后端架构这个词？

• 学习架构的目的：可以更高效的解决复杂的业务问题和技术问题。对架构设计的一知半解会导致，设计不足或者多度设计的现象。
• 架构师思考问题的角度
  • 按出发点划分
    • 从系统整体的角度思考问题，而不是专注某个小模块
    • 不仅要从技术的角度思考问题，更要从业务的角度思考问题，不要发错力
    • 要在有限的资源下，找到一个最优解
  • 从是否具有技术性划分
    • 业务架构：关注扩展性和复用性，描述业务模块间的关系，从业务概念上帮助去理解问题
    • 应用架构：讲系统内部有哪些应用，相互之间如何调用，从逻辑层面讲清楚系统内部的分工协作
    • 技术架构：关注高可用，高性能，可伸缩。讲清楚系统由哪些硬件，操作系统，中间件组成
  • 架构的本质：通过合理的编排，在保证能力实现的情况下，减少系统演进过程中的熵增量，这里的熵增来源于业务的复杂和技术的复杂。
  • 一个好的架构师应该是什么样的

  • 

2. 后端架构需要关注哪些事情？

3. 日常应该怎么去积累架构的能力？

4. 产品经理和业务架构师做的事情到底有什么不同？

•   产品经理的职责
  • 需要告诉用户系统长什么样，需要告诉开发实现了什么样的功能
  • 收集用户的原始需求，整理成一个个的业务流程。每个业务流程有多个业务步骤，每个步骤又有输入和输出和实现的功能。如：

  • 

• 业务架构师
  • 就是把业务流程和节点打散，按照业务域的维度来划分系统模块，并定义这些模块之间的关系，最终形成一个高度结构化的模块体系
  • 业务架构师在设计架构的时候需要关注的点
    • 业务的可扩展性：快速且稳定的开发新的功能
    • 业务的复用性：同样的东西可以不用开发，直接利用。
    • 像支付宝的架构，其实就满足这样的能力。
  • 如何做好复用性：模块的职责定位要非常清晰，数据模型和业务规则设计的要相对固定和通用，做好层次划分（一个底层的复用性会更强）。不管是从全业务的角度上说某个系统的复用性；还是某个系统的中某个模块的的复用性。
  • 从公司整体全盘业务的角度考虑，如支付宝的业务架构变化

    • 

  • 这个第三支付的业务图，也很好的说明了系统复用性的问题

  • 

    5. 如何构建一个柔性的系统？
    • 这个问题说的是如何提高一个系统的扩展性
      • 扩展性说是什么？一个系统的扩展性高，我的理解是新增一个功能，所花费的工作量少，并且对历史功能的影响小。那么想做的上面的两点。我认为下面的几点非常重要：1是要控制系统的复杂度，当一个系统的复杂度高了，想新增一些简单的功能都会变得非常困难。而控制系统复杂度的一个有效方法就是分模块分层，如微服务的思想，中台的思想。2是要提高系统的复用性，当系统或者是模块变得可复用了，可以较少很多重复的工作，同时也降低了系统的复杂度。而提高系统的复用度的关键是要构建一个通用且稳定的数据模型。封装也是一个很好的提供复用和减少复杂度的方法。

5. 架构发展的历史

这里的架构说的是后端的架构的发展。如果要包括前端的话，基本上采用的都是c/s的架构模式

1. 单体架构：服务由单台应用实现，这一个应用可以是部署单台机器或者是多台机器
2. soa架构：整个系统拆分成多个应用，这是种模块划分的思想；应用之之间通过esb总线的方式进行通信
3. 微服务架构：其实算是soa架构的一种实现方式，微服务的拆分方式就是soa的服务拆分的具体方式，服务之间有的组册中心，也是esb的具体实现方式。但是微服务的服务划分会更细致，组册中心也更轻量，相比soa中的定义有些小小的却别。
4. 中台架构：具体的实现方式，也是采用了微服务的架构。但是在微服务的基础概念上映入的分层的概念，它将一些业务上一些共性的，基础的，稳定的，复用性的，能力向下沉淀形成一个基础服务。将一些易变化的，业务相关性强的的逻辑，向上升浮，形成业务服务。通过过基础服务的复用性的提高，来提高整个系统的复用性，同时降低整个企业系统设计的复杂度。而微服务重点提出的是将模块独立成应用的概念，还是不一样的。

6. 要提高系统的复用性需要做好哪些事情？

• 模块边界要划分清楚，模块/系统的职责要定位清晰（要遵守的原则：完整性，指数据要完整；一致性，拥有的数据和提供的功能要一致；正交原则，既然是基础服务，它们就处于调用链的底层，服务之间不会有任何的调用关系，也就是说基础服务相互之间是正交的。比如说会员服务和商品服务，它们代表不同维度的基础业务域，彼此之间不会有调用关系。）
• 模块/系统的数据模型要抽象化，也就是说数据模型的设计要通用性强，要考虑整合所有业务的场景
• 对外提供的接口/消息，也要做到复用性高。如果拿数据的颗粒度来说，不同的业务场景需要的数据的颗粒度是不一样的，比如说商品信息吧，有些场景需要商品的基本信息就可以了，但是有些场景又需要商品的图片，视频，规格等信息。并且这两种场景返回的数据量的差异又极大。所以不管是接口也好还是对外发送的消息也好，都可以考虑提供不同颗粒度的信息。如商品查询接口提供细，中，粗颗粒度的接口，消息也可以提供胖/瘦两种消息体。

上面没有介绍怎么解决系统可扩展性问题？我的理解，可扩展性源于是否有给未来肯新增的功能留下口子；可扩展性可以用增加一个功能的工作量已经对历史功能的影响程度来衡量，所以当能力的复用和业务的隔离做的好时，才有可能提升可扩展性。

7. 如果说架构设计包括业务架构设计和技术架构设计。那么如何做好技术架构设计的部分？

技术架构设计的关注点在技术，这里的技术关注主体在项目中的硬件和软件。具体的工作包括软硬件的选型，已经怎样保证它们的正常运行。设计的目的在在于解决非业务性的问题（如果说业务架构设置是为了解决业务的问题的话）。

• 非业务性的问题可以从：
  • 系统的可用性，核心服务需要达到3个9，4个9，非核心服务可以适当降低标准
  • 高性能，不是绝对的高，而是要提供一个合理的性能，一般从响应时间和支持高并发来衡量。如响应时间，可以根据业务需要来定，一般C端要求在1秒，B端要求在3秒即可。
  • 可收缩性，业务有高峰期和低谷期，系统可以根据业务量进行相应的扩缩容。
  • 成本，提供系统的可用性和性能，免不了增加成本。所以不能追求绝对的高可用和高性能，一定要根据业务量和重要程度来考虑。
• 硬件可能出现的问题
  • 处理能力有限：解决方案包括纵向扩展和水平扩展，纵向值提高硬件的性能，包括提高cpu核数，提高内存，提高宽带。横向指，增加机器数来提升处理能力。
  • 可能会出问题：使用备机，如为应对自然灾害造成的影响，通过异地多机房部署解决。
• 软件可能出现的问题
  • 代码问题
  • 分布式系统可能存在网络分区，数据一致性等问题

8. 怎样保证系统的高可用？

 9. 系统高可用的优化案例

原架构

优化后架构：

改造目的：前端小程序请求将会达到每秒 10 万 QPS，并且预计首日的订单数量会超过 500 万。在这种高并发的情况下，我们为了保证用户的体验，系统整体的可用性要达到 99.99%。

优化点：

• CDN商品信息优化：通过 CDN 供应商，在全国各地构建了多个 CDN 中心，储存静态的商品数据，特别是图片，这样小程序前端可以就近访问 CDN，流量无需通过小程序服务端，缓解了服务端的压力 
• Nginx水平扩张：一台 Nginx 一般可以支持数万的并发，本来这里无需这么多台 Nginx，这是因为云服务商对单个 LB 的接入有网络带宽的限制，所以我们要通过提升 Nginx 的数量，来保证接入有足够的带宽
• 收银端的通信线路备份：原来只通过电信线路和云端机房打通。在这次改造中，我们增加了移动线路，这样当电信主线路出问题时，系统就可以快速地切换到移动线路
• 应用和服务的水平扩展：针对小程序服务端的部署，我们把实例数从十几台提升到了 100 台，水平扩展它的处理能力。在上面的架构图中，你可以看到，小程序服务端依赖了 7 个基础服务，每个基础服务也做了相应的水平扩展，由于应用和基础服务都是无状态的，因此我们很容易扩充
• 订单水平分库：之前负责写入的主库只有一个实例，所以这次我们通过订单的水平分库，扩充了订单主库的实例数，改造后，我们有 4 个主库来负责订单数据写入。数据库的配置，也从原来的 8 核 16G 提升到了 16 核 32G，这样我们通过硬件的垂直扩展，进一步提升了数据库的处理能力。
• 异步化处理：一方面，前台下单要求比较快，后台 OMS 的订单处理能力比较弱（OMS 库没有进行水平分库），通过消息的异步化处理，我们实现了对订单流量的削峰；另一方面，如果 OMS 有问题，以异步的方式进行数据同步，也不会影响前台用户下单。
• 还有在小程序服务端，在用户支付完成或者后台生成取餐码后，我们会以微信消息的方式通知用户，这个在代码中，也是通过异步方式实现的，如果微信消息发送不成功，用户还是可以在小程序上看到相关信息，不影响用户取餐。
• 主动通知，避免轮询：我们落地了消息推送中心，收银系统通过 Socket 方式，和推送中心保持长连接。当 OMS 系统接收到前台的新订单后，会发送消息到消息推送中心；然后，收银系统就可以实时地获取新订单的消息，再访问 OMS 系统拉取新订单。为了避免因消息推送中心出问题（比如消息中心挂掉了），导致收银系统拿不到新订单，收银系统还保持对 OMS 系统的轮询，但频率降低到了 1 分钟一次。同理，小程序前端会通过 Web Socket 方式，和消息推送中心保持长连接。当 OMS 系统在接收到收银系统的取餐码后，会发送消息到消息推送中心。这样，小程序前端可以及时地获取取餐码信息。
• 缓存的使用：当收银系统向 OMS 拉取新订单时，OMS 不是到数据库里查询新订单，而是把新订单先保存在 Redis 队列里，OMS 通过直接查询 Redis，把新订单列表返回给收银系统。在商品服务中，菜单和商品数据也是放在了 Redis 中，每天凌晨，我们通过定时任务，模仿前端小程序，遍历访问每个商品数据，实现对缓存的预刷新，进一步保证缓存数据的一致性，也避免了缓存数据的同时失效，导致缓存雪崩。
• 一体化监控：

系统如何做到高性能和可收缩

补充一个性能基准图：

如何去设计一个秒杀流程？

整体流程设计