心理预期

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

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

  • 

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

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

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

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

  • 

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

    • 

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

  • 

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

5. 架构发展的历史

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

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

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

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