可不可以讲一些架构设计的基础，很多概念都不清楚，网上的概念也不统一

能不能讲讲微服务的调用链追踪呢？

微服务通常根据业务来划分边界，粒度通常是一个独立的业务，具体多大合适不是一开始就决定的，这是一个逐步拆分细化的过程，李智慧老师说任何复杂的架构都是从最简单的应用慢慢演化过来的，就像当年的淘宝发展到现在。单体应用，为了高可用，需要集群多实例部署。查询太慢，访问太慢，加缓存，DB读写分离。业务发展到一定复杂程度，单体应用太庞大，会产生一系列问题。例如开发方面，一个工程几十上百人不停的改动，如何协作，一个人的代码有问题，影响了所有业务。每一个版本的迭代与发布，开发、测试、沟通得花大把时间，可能还会出错，牵一发而可能动全身。运维上，发布一次可以睡个午觉，发布一次影响线上所有功能。资源方面，扩容到几十上百台机器的时候，DB、NoSQL等的连接数撑爆了……

我遇到的比较麻烦的就是数据一致性问题。一个操作需要调用好几个服务，后面的服务异常，前面的服务怎么回滚，如何保证事务。

阅后留痕 单机在中间，往下研究是多线程高并发，往上研究是分布式高并发，往下是线程级别，往上是进程，集群级别，不过他们的根本是为了速度，为了快，为了快点将任务做完。 1:什么是分布式？ 我认为相对单机而言，分布式至少是多机部署，多机共同分担任务处理 2:分布式核心解决的问题是什么？ 我认为本质如浩哥所言，一是增加系统容量，二是实现系统高可用，其他还有并行开发、服务解耦 3:分布式引入的问题是什么？ 数据不一致性，测试、运维复杂，排障链路长 4:分布式实现的难点是什么？ CAP 5:目前有哪些分布式的最佳实践？ 不太清楚？ 6:分布式必备技术有哪些？ RPC、MQ、各种集群存储系统、负载均衡、容器化部署

服务化过程中代码层面需要注意以下几点1.序列化。接口的入参出参需要序列化;之前在单体应用中适用的service接口，可能不适用远程调用，需要改造，如匿名函数作为参数的接口。2.既当入参又当出参的接口，在服务化后，不再适用，需要改造。即调用更新接口后，需要调用查询接口以返回正确的值。3.服务化后，要考虑写接口是否是幂等。4.考虑接口超时，设置合理的超时时间。

将SOA架构描述成 IoC（控制反转）和 DIP（依赖倒置原则）设计思想在架构中的实践，真的直击本质啊，眼前一亮。

@ lfn 当然不是

@ helloworld 关于技术细节，我会单开另一个系列讲各种Pattern。敬请期待。

公司的新产品研发基本上是沿着分布式，微服务这个路线发展的，我们的产品是行业软件，to b的，发现分布式之后定制研发成本增加了不少，另外可能很多客户的体量还达不到需要部署微服务的程度，没法平摊越来越高的运维成本，所以最新的版本同时保留了单体应用和微服务架构两个方向的产品，适应不同的客户要求。这种一国两制的方式应该是挺正确的选择。 虽然微服务是将来的方向，如果只是一套系统自己运维，客户是自己，那自然是没得选。如果是离岸交付，那还是要权衡一下迈进的速度。