【读书笔记】企业IT架构转型之道 阿里巴巴中台战略思想和架构实战

首先声明一点，读这本书的目的不是为了建设中台而读，是比较感兴趣他们的建设过程中的实践和思考。

以下内容是自己的一些总结和思考

1、架构演进

没有一尘不变的架构，架构是需要持续演进的。淘宝的架构进行了持续演进，从烟囱、到分布式再到共享式的架构，由原来的淘宝团队、天猫团队各自运营各自的商品、客户、交易等到后来出现共享服务，最终由该中心提供共享，使得架构在演进的过程中，共同服务也得到了沉淀和复用

2、试错和创新

在发展的过程中，无论什么行业有红利，大家都会去尝试分肉，所以在业务发展的过程中需要保持一种试错和创新的精神，不能单单只做一块，应该鼓舞一部分人进行业务试错，这样才可以保持业务的竞争力和活力，只有你真正的赋能他人，他人才可以很好的去做试错和业务创新，文中提到的supercell的团队就是如此，7-8人为一组，去开发产品，放在市场进行试错，这就是一个很好的案例，他可以鼓动员工去观察生活，发现人的需求，然后去做业务创新，最终达到带来商业效益

3、CRUD BOY

很多人说现在的开发，自己都是CRUD，如果你每天工作每时每刻都是在CRUD，没有时间做其他事情，那真的可能在工作时间只能做一个CRUD BOY。但是你是否想过要改变这种，参与方案的设计，不单单只做一个执行人，你要做需求进行深入分析和了解，知道需求的背景，这样你可以做设计，来进行自主开发，当然深入了解了需求不一定能设计出很完美的方案，你还需要知道你的上下游以及依赖和链路是什么样子的，这样才可以形成一个闭环。当然，如果你现在已经对你负责的业务系统具体操作流程、数据模型掌握，你是否对业务的发展具有你自己的理解和想法，对业务流程如何进行更好的优化，做业务创新，或者说你是否考虑换到另外一个领域去熟悉和掌握，达到整个环形业务的掌握。这样才可以算是懂业务。

4、微服务

最近几年比较火的微服务也算其中之一，大家都在将一个大的进行拆解，目的是为了快速迭代，服务具有更好的可扩展性，降低系统的复杂性。如果使用了微服务，是否是根据领域进行服务的拆分，服务的边界是如何定义的？服务在线上的监控、请求的链路、追踪和分析如何做的？是否有采用美团的CAT、或者开源的Skywalking、或者Zipkin+sleuth来实现链路方面的追踪和分析，是否有用到prometheus来对jvm、CPU、IO等信息进行监控。服务上线只是一个开始，重要的是后期的运维和运营，如何积攒数据，来做商业分析，又是另外一个重要话题，数据是石油，没有数据无法得出任何靠谱的结论

5、思考性问题

无论是作为业务开发还是其余角色，都需要思考自己服务的调用链路、调用场景及数据是否合理？服务的调用趋势是怎么样的，产生的瞬间峰值是多少？是否达到了服务能力的最高水位？

在业务流程设计中，该服务所依赖的服务有哪些？整个链路的依赖路径是什么？核心服务是什么？如果出错，会有什么影响？一次请求的耗时点在哪里，怎么去分析和改善？在过往的异常情况下，哪里出错率会比较高？哪些服务的业务链路是处理的瓶颈