作为IT新手，这个专栏让我快速高效的对公司的整个架构体系有了了解，工作时更从容了。

胡老师，我在新浪大厦3楼，谢谢你的专栏分享😄

微服务实践的第一个课程，理论结合实践，物有所值

从购买课程开始，花了两天多时间看完，当然这是第一遍，还会有后续的第二第三到第N遍。个人觉得胡老师的这门专栏非常非常Nice(膜拜)。本人在一家公司也经历过一年多时间从单体服务重构到现在的微服务集群，但是在其中充当的角色就是开发人员，在这之前对微服务了解的非常局限，当看完老师的课程自后让自己对微服务有了一个全局视角的认知。老师在课程中的架构思路非常清晰和完整有序，每介绍一块内容的时候先从全局视角分析罗列出涉及到的点，然后针对每个点进行详细的分析和思考，受益匪浅！另外当然极客时间上的专栏都非常高质量，庆幸有这么个平台并且有这么多大牛分享多年的经验

我的入门专栏，师傅领进门，修行再个人。感谢老师，我一定加油

写的太好了，收货颇多。

我现在对拆分的考量： 一是业务维度聚类，业务和数据关系密切的应该放在一起。 二是功能维度聚类，公共功能聚合为一个服务。 三是人员聚类，这是个实际中的考量，如果某几个业务就是这几个人比较熟，那么最好放在一起，未来开发部署都好办。 四是性能聚类，性能要求高的并发大的和性能要求低的并发小的，要分开为不同的服务，这样部署和运行都独立，好维护。 还请老师指教

是否需要拆分要看目前公司项目的具体的情况，如果现有架构无法满足当前业务发展速度，比如构建一次要半天，上一次线经常搞通宵，牵一发而动全身，那么这个时候可以考虑一下微服务，拆微服务势必会提高运维、问题追踪、分布式事务等复杂度，所以微服务整个技术栈都要考虑进去

不要为了微服务而微服务，微服务需要业务达到一定的量级，也需要运维能跟得上

在我看来，用通俗的话来讲，服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。这句话真的讲的很透彻👍