架构师，怎样才能搞定上下游客户？

本文主要是介绍架构师，怎样才能搞定上下游客户？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本系列前序文章索引：

架构师，在开展工作的过程中需要对接老板、产品、项目、开发、测试、安全和运营等各种岗位角色，他们都是架构需要关注和服务的内部客户，他们的痛点就是架构工作的驱动因素。架构师就是要用专业技能“搞定”这些角色的需求，输出大家都能接受的解决方案，大家好才是真正的好。为了达成此目的，我们必须知道不同岗位的关注点。

老板产品

老板的主要职责就是定方向、找人、找钱，他对架构设计的要求就是在给定的预算、时间范围内研发出软件系统，推动公司的战略或战术得以实现，也就是说架构方案不能过于理想，不能超出预算和截止时间。自从苹果公司的乔布斯封神之后，现在的互联网公司都崇尚老板担当首席产品官，例如腾讯马化腾、微信张小龙、百度李彦宏等等。产品经理需要思考打造什么样的产品才能达成公司的战略或战术目的，他要综合考虑产品是否满足功能、质量和商业等需求，满足功能需求只能达到及格线，易用性、交互体验、性能、可靠性等质量需求能否满足才是产品达到优秀的关键，以及从商业角度考虑选择什么时机将产品推向市场，有节奏地推动用户和业务的不断增长等。

任何技术都是服务于业务的，架构主要是承上启下的作用，架构设计需要将老板和产品的战略战术规划跟开发实现衔接起来，例如：公司准备进入某个新领域，但在没有足够把握的情况下先推出一款产品试试水，这个阶段的架构设计就不能太超前，而是要尽量简单轻量，以便开发团队能够快速将原型产品开发出来，推向市场并收集真实用户的反馈，验证想法。如果发现原先的想法过于纸上谈兵，那么接下来就要尽快调整方向了，这时候架构过于复杂反而不利于调整。如果经过试水验证发现产品找准了市场切入口，用户和业务都开始快速增长，那这时候就需要考虑做架构升级了，必须预见到后续业务发展趋势，预留一些提前量，确保技术不会托业务发展的后腿。

2. 项目管理

我们都知道，不管是传统瀑布式，还是敏捷迭代式，项目管理主要关注范围、进度和成本铁三角，以及满足上述三个维度约束下确保质量。那么从服务好项目管理这个内部客户看，架构设计必须要遵从范围、进度、成本和质量等约束，否则项目组都解散了，再好的架构也无用武之地。

范围，指需求的范围。传统瀑布式项目的周期较长，通常在立项之初就明确全量需求范围了；敏捷迭代式项目是小步快跑，需求不是一次性确定的，而是增量添加的。针对不同类型的项目，架构设计就需要给出相应的方案，瀑布式项目可以搭配完整超前些的架构，而迭代式项目的架构必须是易于升级演的。
进度，指研发的进度。时间是项目成功的关键因素，时也势也，再好再完美的产品错过了上市的最佳时机，最终也将被丢弃到垃圾桶当中。架构设计必须考虑采用哪种技术栈才能保障项目进度，最新的技术成熟度和社区支持不够，或者开发团队成员还没有足够的知识储备，很容易将项目拖入到无止境的延期当中。
成本，指研发的成本。任何项目都是考虑投入产出比的，架构方案中有没有引入商业化的中间件产品，如果有就需要预算采购，如果采用开源产品替代，那就需要投入额外人力研究掌握。另外，技术栈难度高低也会影响人力成本，架构方案将决定团队是否可以并行开发等，架构设计必须在保守和激进间做好权衡。
质量，指产品的质量。假如现在我们在满足进度、成本等要求的前提下交付了一款功能齐全的产品，但产品存在明显的质量缺陷，就像销售到用户手上的汽车存在安全隐患，那这样的产品不仅不挣钱，还要赔钱。从架构维度看，我们也可以围绕质量这个要求调整设计，让系统变得易于测试、容灾容错性更强、弹性更好等。

3. 开发测试

开发测试要基于架构设计做子系统的概要设计、详细设计、测试方案设计和测试用例编制等，从这项下游工作来看，开发测试就需要关注系统的逻辑划分，即系统被分解成几个子系统，每个子系统分别承担什么职责，关键业务场景的交互流程是怎样的，子系统之间采用哪种交互机制和通讯协议等。如果缺失这些信息的输入，我们开发测试的工作就会受到影响，严重会导致无法交付合格的产品。

除了承担部分设计工作之外，开发测试主要职责就是将文档图纸上的设计真正落地实现，这就涉及到具体技术栈的选型，也就是我们程序员构建虚拟世界的工具。若以 Web 应用程序开发为例，技术栈的选型主要包含以下几个方面：

操作系统 OS：主要包括 Linux \ Windows \ Android \ macOS \ iOS \ watchOS \ tvOS 等，不管是服务器还是客户端都有多种选择，我们必须对它们要有概略的了解，然后根据需求和自身情况选择合适的。
运行时 Runtime：主要包括 Java \ C++ \ Python \ Ruby \ PHP \ C# \ JS \ C \ Perl \ Shell \ VB \ AS \ Scala \ R \ Go 等，每种编程语言都各具优势，例如：Java 生态圈非常强大，Python 特别适合人工智能领域，Go 常用于构建云计算基础设施等。
容器 Web Container：主要包括 Apache \ Tomcat \ Jetty \ GlassFish \ Weblogic \ WebSphere \ JBOSS \ Nginx \ IIS 等，前后端分离、静动态资源等场景需要不同的容器。

如果项目压力很大，那么选择熟悉的技术栈是合适的，这样我们就可以聚焦在业务实现上，不用操心技术维度导致的问题。如果项目压力适中，团队也希望掌握一些新技术栈，以便后续可以使用新技术开发新系统，那么选择次新的、主流的技术栈是最好的，在项目中实践熟悉新技术，完成团队研发能力的升级更新。

4. 运维运营

系统在发布上线之后将会被移交给运营团队，但运营团队的关注点跟开发测试不同，他们关注系统能否稳定运行，在处理业务请求时的耗时长短、吞吐量等性能表现，当业务量爆发式增长时系统是否具备弹性伸缩能力，系统在长时间运行过程中的稳定性、可靠性和鲁棒性等。另外，任何对用户有价值的系统上线之后都要面临黑客、羊毛党的攻击，系统必须要有安全性保障，确保用户个人信息和业务交易过程的安全。俗话说：百密必有一疏。考虑得再周全，线上仍然会发生出乎你意料的事情，系统必须要有实时检测、提前预警和事后恢复等机制，运营的职责就是系统能够提供 7*24 不间断的服务，不让系统拖业务发展的后腿。

在传统业务模式下，我们企业的大部分软件系统都是用于办公自动化的，这些系统的用户数量是相对稳定的，运营团队只要保障这些系统稳定运行就可以了。但是到了互联网+时代，企业的核心系统都是面向线上全网客户的，并发访问量的波峰波谷是不断交替出现的，最大峰值流量也很难预测，这时候系统的弹性伸缩能力就显得特别重要了，运营团队比较关注系统是否方便扩容或缩容，是否支持跨数据中心部署，是否支持集群的克隆部署等。这些诉求都要纳入到架构设计的驱动因素当中，确保最终输出的架构设计方案能够满足上述要求。