可参考才是有价值的，架构设计的技改之路从来都不容易

溪云阁：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。

有本书说：会使用框架不一定能成为一个优秀的架构师，但优秀的架构师一定会使用框架。架构师除了会使用工具，还需要有架构设计思想和性能调优技能。在设计上追求简单有效，不做过度设计。

企业级别总体架构设计

目前很多企业都是以项目为主，一个项目撑起整片天的大把存在，这样的情况在设计上需要非常把握一个度，尽可能以项目为导向做到点到即可，年轻人要讲武德。但是当我们有了几十个，几百个甚至上千个应用的时候，此时需要的不单单是单个项目设计，更需要整个企业级别的总体规划及总体设计，在这个上面需要做顶层思考与设计。

大公司有大公司的好，小公司有小公司的温暖，大公司很多时候人情冷暖心里自知，小公司小团队常常存在家庭般的体贴。在大公司里面做技术，由于公司体积庞大导致经常难以看到这个商业的全貌，在规划上非常吃亏，除非站在非常高的层面去俯瞰整个体系；小公司又缺乏最基础的流量及各种中间件的应用场景，或者在使用了某些技术框架后也只是存在单纯意义上的使用，不是为了贴近业务场景；中型公司基本上针对这两者都能兼顾到，此时在做整体的企业级架构设计的时候往往比较容易落地。

说起来简单做起来难，落地这两个字是非常考验能力，整个企业整体架构设计需要在技术，管理，业务三方做取舍，游刃有余的同时又能动态切换，架构师在设计上还包含业务架构，应用架构，数据架构，技术架构4种，但是现在很多都是总包做，没办法的事。

灵魂所在的应用架构

小孩子学画画从来都是从一张白纸开始，一笔一画进行涂鸦。在项目或者企业的开始阶段，应用架构的设计就跟小孩子画画一样都是从一张白纸开始，也是一个不断试错、不断进化的过程。这样子的架构其实就是起到一个承上启下的作用，承接功能需求，下连代码编写，这就是应用架构灵魂所在，它是最快能体现出价值的东西。

从功能设计来分析设计，涉及到各类UML图，领域图，整体架构分层，核心组件或者代码的编写，这些都是紧密结合并如铜环般串起来，环环相扣。整体的架构关注点永远在于职责问题、领域边界、应用关系、存储设计、部署。

任何东西都是可大可小，做大了做复杂了容易增加开发人员的压力，直接导致项目延期。每一个应用的分层，需要做到简单有效，易用学习成本低，业务场景支持性强等。在我们设计上，参考了DDD的边界思想设计好我们的接口边界，并限定统一的出参入参来进行区分处理，这样子的设计其实就是还原了机器最原始的输入输出设计。

人都是懒惰的，特别是研发人员，总想着我做了一个东西后面不用写了，所有的东西都来复用它；但是研发人员又是最勤奋的，他们想方设法做了一个适应了所有方法的东西，花费了巨大的时间。其实这种设计往往带有很大的危险性，容易在后面的运维上增加运维的时间并且让这个系统的复杂度变得非常高。

从架构到“管理”

任何架构都是要落地的、要标准化、要不断演化的，这部分是需要通过融合技术架构与组织架构来实现。每一个角色的转化，从架构师到技术管理，所关注的角度跟层面并不一样，单纯的留在技术层面演化成关注技术在商业的应用价值，技术跟业务的契合度，整个技术团队的文化、能力不断成长。

微服务的出现是个契机也是个痛苦的根源所在。很多企业刚开始使用最简单的单体架构，开始往微服务架构迁移，这就是技改的过程。这样子的过程无论项目大小都是痛苦的，项目小投入少但是微服务所需要的资源多，项目小涉及到的业务量多，很容易变成为了不影响业务而小改，不敢全盘推倒去做而采用慢慢吞并方式去做，最终变成单体与微服务并行的存在，你却又无可奈何并且筋疲力劲不想继续做，反正对上层的领导有交代就行，他们更加关注的就是系统，业务的稳定性。

技改其实并不是单纯的技术改造，而是道路的演变，但是技改无论对大公司或者小公司而言，都是非常痛苦的，“小赌怡情，大赌伤财”。那什么样的技改才是正确之路，应该是能驱动公司业务发展的技改才是正确之路，让技术与业务互相融合，互相匹配，同时技改的时候一定要尊重食物的发展规律，不要为了技改而技改，那就纯粹为了炫技。这让我想起以前面试过一家公司，从各类语言问到架构，从架构问到数据科学，范围很广，技术很牛逼，一问没啥量，一年顶了天就1T非架构化数据，量能也就不到上万人。WTF，垃圾。

每一个技术团队都是可爱的，不像外面穿的死气沉沉，如果一个部门整天都是死气沉沉，那就是这个部门领导有问题，让整个部门充满激情活力，从固步自分到分享为乐，这就是团队文化的建设。信任是团队非常重要的存在，只有这样子出来的团队文化，才能真正留得住人。