在之前写事故驱动开发的时候，提到过，在企业中的项目进行开发时，只要是自己方便，一个人可以用拆分和收敛同时作为自己的标准。所以大家都是双标狗。
目前业界的微服务方法论一般也没有固定的套路，比如在 《Building Microservice》
一书中，作者也讲到了服务之间协作的时候，可以选择编排(orchestration)和协同(choreography)这两种方式来对服务进行架构。所以在拆分阶段，就没有什么硬性的标准了，每个公司可能风格都有差别，并且都可以阐述出自己的条条以支持自己的架构是“正确”的。
显然，这件事情没有绝对正确的解法。无论哪种拆分方式，都会遇到业务边界的问题。在大企业中，顶着“架构师”头衔的这些架构师们根本就不会管任何实现上的细节。相对较大的业务需求，一般也是一线的
微服务的布道师们特别喜欢鼓吹一个观点：拆分微服务之后，我们可以随意地对小模块进行重构，选择最合适的技术栈，并且如果写失败了随时对这个模块拿其它语言进行重写。这一点被大多数布道师当作微服务的重点优势。
但是布道师们有意地把这样做所带来的问题忽略了，或者更恶意的是，他们明知道有问题，但是不说？啊哈哈。
一个公司业务上有多种语言的话，理论上可以吸引到各种“语言的人才”。这确实不假，并且可以提供给各种语言大佬一个互相掐架的优秀竞技场，只要干掉对手(其它语言的大佬)了，我就可以扩张团队，让团队把所有其它语言的模块用我们擅长的语言重写一遍，善哉善哉。小伙子们一年的事情就都安排上了。
但是显然这种说辞是有问题的。在现行的微服务架构下，除了业务本身的研发人力投入之外，在业务之外的支持系统的研发工作也有很大的工作量，比如典型的，服务发现，熔断，优雅重启，存储系统
client，
在架构师们很喜欢的 Domain Driven Design，即 DDD 中，第一课就是教导团队形成自己独有的通用语言(Ubiquitous
Language)，作为业务概念沉淀下来。
作为非英语母语的国家，我们在日常交流中使用的是中文，在公司业务战略描述上使用的是中文，在高层进行任务拆分的时候使用的是中文，在领导安排工作的时候使用的是中文。唯独到了具体实现，即代码这一环节便变成了英文。当然这里我们不考虑有些公司会有汉语拼音这种尴尬的情况。
两种语言天生便有难以填平的鸿沟，在业务人员编写代码时，从中文到英文的转换，往往丢失一部分业务信息，产生一部分信息噪音，或者发生概念上的偏移。
英文语系的人对业务进行建模时，与业务方(领域专家)交流时，产生的概念和反馈可以直接落实到代码上，他们所使用的词汇不会发生变化。而其它语系的人就会在编写代码的时候发生概念偏移，比如我司是做打车业务，
流式计算系统是近些年发展较快的领域，虽然发展迅速，但实际上直到现在都没有能让所有人都满意的系统出现，哪怕是 flink/blink。
流式计算的理论基石是 leslie lamport 在 1985 年发表的论文《Distributed Snapshots: Determining
Global States of a Distributed System》。首先将分布式系统中的进程定义为 process，然后将进程间的连接定义为
channel。当需要计算全局状态时，因为没有能够全局同步的时钟，所以需要有别的办法能够记录整个计算集群的状态值。
process 及连接 process 的 channel
Gopher China 讲师尘埃落定，可惜今年没有获得去讲的机会，把之前的内容总结在 Blog 里吧~
由于 MySQL 类带 Schema 类存储系统的设计问题，不支持快速的列扩充，实际业务中，一个业务实体的属性随着业务的发展是一定会膨胀的。这样持续在
MySQL 上加列往往就会捉襟见肘。比如我的历史业务订单表有 50 个字段，虽然会对历史数据进行归档，但在线上还是会有千万甚至亿级的数据，这时候在 MySQL
上加列一般使用 PTOSC 或者 Ghost 来改表，两者设计有区别，但缺点都一样：慢。
