"嫦娥4号"航天器刚刚首次登陆“月之暗面”，国人欢欣鼓舞。我也凑个热闹，说一说微服务的“月之暗面”。
微服务的迅速推广有原因的。从国内各公司遇到的问题来看，一般都是处于快速成长期的互联网公司，不论是流量、用户数和订单、业务的种类，还是运营的复杂度上来说，都遇到瓶颈。由于前期不注重质量，技术团队当仁不让的成为问责对象——开发进度慢，“上个线就崩”，成为普遍现象。系统“耦合”严重，一般是上下共识。
怎么拆？——微服务听上去是个灵丹妙药。
正好在技术上，Spring框架[2]和基于Web的SOA和REST架构[3]经过十多年的发展，日趋成熟。解决注册发现、负载均衡、熔断降级等机制的开源框架不断涌现，比如Eureka, Zookeeper, Hystrix等等。Netflix本身等其他公司的“成功经验”也作为微服务的实例印证。
如果把微服务当作一个产品，从营销角度来看的话，它作为一个新鲜事物，听上去简单易懂（实则似懂非懂），工程师上手快体现技术高水平，又有架构师们的号召，还有国内外技术舆论支撑，完全满足作为一个爆款的前提条件。
微服务应用到了2018年下半年，突然听到看到很多抱怨，其中不少也是凡普趟过的经验教训。主要体现在以下几个方面：
1. 测试困难
2. 部署困难
3. 运维困难
表现形式上都是各微服务系统交互复杂：一个一个的“微“服务之间的调用关系是什么？这令测试时可能不充分，不能覆盖大部分用例；令部署和运维时不知道依赖关系，说好拆分后不相互影响实际上还是相互影响，而且还不能第一时间像大泥球时代一样被发现。
这凸显了一个微服务架构中，如何切分微服务，或者边界问题。
于是又去找仙丹。这回是领域驱动设计Domain-Driven Design (DDD)[4]。有按名词分的，按动词分的，但是其实没有明确的切分标准。又有方法论比如Event Storming [5]。Alberto Brandolini来京的时候我还专门讨教了我的疑问。对于简单的业务和模型，任何一种方法都是有效的，但是我发现对于实际复杂的业务场景，特别是国内这种各大公司什么都想做的情况，没有答案。
我倒反而释然了——微服务架构还是要回归到建模和对业务深入理解的架构本质工作上来，按照业务属性，以及康威定律[6]。微服务只是一种切分边界和团队责任的方式，语言中的根据包package或者jar包的切分也是一种方式，只是物理上，微服务的隔离做得更好一些。
隔离形成约束是工程上常见的一种做法。比如对于编程，Clean Architecture [7] 中说到：
1. 结构化编程是对程序控制权的直接转移的规范和限制
2. 面向对象编程(OOP)是对程序控制权的间接转移的规范和限制
3. 函数式编程是(FP)对程序赋值操作的规范和限制
其中，OOP似乎就是对应名词划分的边界，FP就是对应动词划分的边界，而整个微服务就是一个结构化编程。
所以微服务，作为一种松散的架构，必须对应着响应的规范、原则，也就是服务治理，比如服务发现网关(Gateway)是一种方式，杜绝除REST以外的IPC调用也是一种方式。微服务是需要为“失败”设计，并且以演进的方式设计的。Martin Fowler的原文中说得好，不再赘述。
因为微服务实质上是一种隔离措施，而容器化是近些年操作系统层面资源隔离做得最好的，所以容器化及其管理是一个必须。
复杂的交互需要各微服务正本清源，注册发现自己，版本化发布服务也是一个必须。
测试自动化，特别是串起各微服务的回归测试自动化，虽然很奢侈不好做，也是一个必须。
实时系统监控上，需要各服务的调用链路的可视化。
另外常常忽视的是，团队组织上，需要绑定微服务的责任制。这不是在事故时要追究团队的责任，而是在服务治理发现中方便找到响应的团队解决问题，还有就是在频繁的组织变动中避免出现微服务“孤儿”。
最后给大家提个醒，在建立微服务的过程中尽量避免以下问题：
1. “为了拆而拆”，架构是为了提供稳定可持续发展的业务，而不是为了美丽的架构；
2. “只管生不管养”，也就是说要建立微服务的可持续维护和运营的机能：版本化，监控等等；
想一想，大家在实施微服务中出现的问题，其实是软件工程中普遍的问题，并非为微服务特有，但是任何架构和方法都有“月之暗面”。每一个工程师都必须有他的“嫦娥4号”去发现。全盘肯定和全盘否定都是“Too Simple, Too Naive"的表现。
References
[1] Microservices, James Lewis and Martin Fowler, https://martinfowler.com/articles/microservices.html
[2] Spring框架，https://spring.io/
[3] REpresentational State Transfer (REST). https://restfulapi.net/
[4] DDD手册, Eric Evans, https://domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
[5] Event Storming, Alberto Brandolini, https://www.eventstorming.com/
[6] Conway's Law, Melvin E. Conway, http://www.melconway.com/Home/Conways_Law.html
[7] Clean Architecture, Robert C. Marin
