1. 为什么中台不好做？为什么各个大厂都开始逐渐的抛弃中台的设计？
实践是检验真理的唯一标准，一句话，实践下来效果不好。钱花了，但是开发的效率并没提高多少。
本身的想法很好：中台可以都大企业的一些重复的功能做一个收整，归并一些重复的系统。可以减少维护的人力和物力成本。专业的人做专业的事，提高系统的设计质量。
但是实践下来的结果却是：
- 企业内存原因
- 业务之间通用化的功能有限，新的业务用不上中台的能力。中台功能的复用性，并没有被充分发挥。（一般来说中台的能力来源于老的业务系统， 并且中台对老业务系统的执行优先级也会更高。新的业务系统，可能是需要一些新的功能，这些功能中台没有，且被支撑的优先级低。这与新系统需要更快的功能迭代是相冲突的）
- 开发的系统少了，但是中台人员和业务人员的沟通成本增加了。（写的代码是少了，但是需求划分，中台和业务系统间的开发和联调的成本变高了）
- 外部原因
- 互联网的发展受限，企业都在砍掉一些不挣钱的部门和项目。中台没有新的项目接入并且中台的人力和物力成本也很高。所以中台部门也成为各大企业裁撤的部门。
人工智能的时代，架构师会被替代吗
按我的理解，chatGPT的时代，一切都是可以被替代的。chatGPT具备具备逻辑推理能力，而像sora具备人的对世界物理规律的理解能力。并且人工智能具备极其全面的知识库和强大的计算能力。所以理论上，他可以替代世界上任何一个工种，只要给他喂足够优质的训练数据。这里没说创新的能力，因为如果有创新能力，意味着它有自我意识，到那时人类就危险了。
架构设计的基本原则
简单，适用，逐步演化
架构师要解决系统的核心问题
解决性能，高可用，扩展性，复用性，可伸缩性，成本
如何成为一个精打细算的架构师
这里我主要想说成本控制和风险控制
一个项目中问题这么多，架构师应该关注什么问题
那当然是架构问题，主要考虑项目的可用性，性能，扩展性，成本，可伸缩性，这些是偏技术架构的一些维度。
除此之外，还有关于业务架构的考虑点：可扩展性，可复用性。这块和业务比较紧密，离我们程序员也比较近。像后端开发的分模块，分层开发和微服务架构，其实都是为了提高扩展新和复用性。
架构变更需要很多人的协助，怎么让其他人来帮你
处理好和同事间的关系，想想架构变更工作给其他带来的好处，并用此说服对方来帮你
高可用的架构怎么做？有什么标准化的处理方式？
考虑角度：避免发生，快速发现，快速恢复
设计原则：
避免发生：全链路冗余无单点，非强依赖链路要可降级，接口要可限流
快速发现：全链路监控
快速恢复：提前准备故障处理预案，有条件可以提前演练