作者：毕玄
文章来源：微信公众号HelloJava
上两篇讲了系统设计首先要考虑的两个问题，一是为什么要建设或重构系统，确保系统设计的出发点的正确性，二是根据建设系统的目的形成可衡量的目标，确保最终产出的系统和最初建设的系统的目的是一致的，这篇接着继续讲，如果要达成系统设计的可衡量的目标，到底面临了一些什么核心问题，只有明白了面临什么核心问题，才能更加明确的进行系统设计来解决这些问题。
还是用我自己的经历来讲这个话题。
最开始做HSF的时候，为什么要做HSF是比较清晰的，在可衡量的目标上也有一个大概的要支持每条上亿的服务调用，但由于当时的技术功底问题，导致了在提炼核心问题上是有很大差距的，这些也造成了后来HSF总是不断的重构、修修补补之类的，所以我从来就不认为技术功底不好的人能做好一个架构师，架构师绝对不是看到的随手画几个框那么简单，那通常只是个结果，但要合理的把框画出来是需要基于非常坚实的技术功底，HSF在最初设计时认为的核心问题就是怎么实现一个易用有服务定义的RPC框架，但对于如何支撑好上亿的交互调用量，服务化上线后给业务研发会带来什么问题（例如排查问题变复杂了），在核心问题上是有很大的缺失的，例如HSF上线后才发现的中间的负载均衡的问题，而这个问题是导致了HSF结构重新设计的，这个后来回头看就会发现如果是一个知识面更广的架构师可能一开始就会想到这个核心问题，所以如果回过头去看，HSF这样的框架，要达成目标，要解决的核心问题应该是：
- 易用、能支撑上亿次服务交互的RPC框架；
- 服务间的软件负载均衡问题；
- 服务交互的问题排查；
在做T4（容器）的时候，目的、目标都还比较清晰，问题的提炼现在回顾也做的还ok，T4要解的核心问题为如何实现在一台机器上跑20个应用，T4出现的问题更多是对于核心问题的设计方案上，这个到下篇讲围绕核心问题的系统设计上再写。
到了做异地多活的时候，目的、目标的清晰化都ok，对于异地多活而言，要做到在中国多个城市都可同时支撑流量，并且可在几十秒内完成流量切换，异地多活中物理距离所带来的网络延时是不可突破的，怎么做到多地活且流量可动态切换，要做到这个，面临的核心问题是：
- 如何将流量进行切分，且让请求的整个处理过程能封闭在local完成；
- 如何保障异地多活后的数据一致性？
到了最近几年做统一调度的时候，整个做系统设计的思考框架我觉得算是比较熟练了，所以统一调度的目的、目标都很清晰，结合当时的情况，要实现统一调度的目标，其面临的核心问题是：
- 如何实现一套在线业务资源的调度系统去满足各种资源诉求？
- 如何尽可能扩大统一的资源池，解决资源池统一面临的资源竞争、资源被抢、多种不同资源规格等问题？
- 如何实现在线业务、离线任务两套调度系统的互通？
- 如何解决在线业务、离线任务混合部署时的资源竞争的问题？
从上面的这些cases来看，可以看到，从可衡量的目标映射到技术层面要去解决的核心问题，是很需要技术功底的，对于工程类型的项目、产品而言，工程经验在这个时候也会特别重要，而通常我也觉得这是衡量一个优秀架构师很直接的地方。
在提炼出了问题后，就可以开始围绕问题来进行核心的设计，在这个部分也是走了不少弯路，才逐渐意识到架构师必须具备的一些能力。
这个系列的文章会按照聊聊系统设计的套路来写，写的时候会理论结合实践，实践主要是讲我自己在相应的点上的一些经历：
- 系统设计之系统建设的目的
- 系统设计之系统建设的目标
- 系统设计之达成目标的核心问题 - 本文
- 系统设计之解决核心问题的设计
- 系统设计之设计原则
作者简介：
毕玄，2007年加入阿里，一手打造了HSF，十多年来更见证参与了阿里在基础技术上的演进与发展：如淘宝在2007-2009年的分布式应用架构升级、2013-2016年的阿里电商异地多活架构升级等。
