作者回复: 中台可以有不同的视角，在业务方和管理层的视角中，中台是一个偏向业务和组织的概念。在架构师和技术人员眼中，中台偏技术平台。不管何种视角，中台的本质是业务/组织或技术能力的模块化和复用，最终目标是业务的规模化发展。

作者回复: 是的，业务中台边界和划分不容易把控，而且随业务和团队会一直变化，这就是需要引入业务架构师和他们的价值所在，根据企业上下文和业务发展需要，不断调整业务中台的边界和划分，尽可能将企业业务能力抽象封装模块化和重用，提升研发效能，赋能业务创新。

作者回复: 有本质区别，中台更多是一个组织和业务的概念，技术架构在其次。 你简单可以这样理解，我们编程经历了面向过程 -> 面向对象 -> 面向组件 -> 面向服务 -> 面向平台(中台)的过程。 普通程序关注过程/对象/组件这些底层抽象层次。 架构师关注服务这个中间抽象层次。 但是在技术/业务总监或者CTO的眼中，他们关注中台-把业务能力+团队作为一个重用单位，利用中台去支持业务的迭代和创新，是更高维度的抽象。

作者回复: 技术中台主要是企业管理层和架构师，需要理解和掌握，对于一般开发人员，简单了解即可。

作者回复: 如果是企业新系统，没有遗留系统负担，PaaS可以一步到位考虑Kubernetes平台(如果企业研发资源和能力一般，建议不要自建而是采用云服务，例如阿里云k8s)，k8s已经覆盖了服务发现，应用配置，容器调度和部署，自愈和自动伸缩，资源隔离和配额，分布式存储，分布式任务等微服务基本关注点，再配合一些其它一些中间件(网关，oauth2，消息，限流，分布式数据访问层，日志/调用链/metrics监控和告警，其中部分中间件和开源产品可以参考我之前课程《微服务架构实践160讲》），即可搭建一套比较前卫的PaaS平台。当然，企业实际PaaS平台的构建不是一蹴而就，需要长期的投入、运维、迭代和优化。

作者回复: 中台也是模块化和平台化思想，不光是技术架构，还有组织甚至业务也可以模块化和平台化，理解思想即可，没必要太纠结术语。

作者回复: 用户管理和登录认证的功能可以做在一起，也可以分开，各有利弊，具体要看企业上下文，一般企业早期是合在一起的(考虑维护成本优先)，到一定解决可以考虑拆开(考虑微服务和职责单一)。 合在一起的参考产品:fusionauth.io 独立授权认证的参考产品（不带用户身份管理）:https://github.com/ory/hydra