再读Microservices-A definition of this new architectural term

前言

文章就是那种隔一段时间拿出来看看，总能获得新收获的文章。James Lewes和Martin Flower这篇就应该属于这一类，第一次读这篇文章应该是在2015年吧，读完了感觉云里雾里的，感觉懂了又感觉有点蒙，尤其是关于Product not Project那部分以及围绕业务组织团队。经过三年再看的时候才感觉到确实如此，所以本周就把重读一遍的收获在这里写一下，也算是一种特别的体验

核心内容

1.组件化的服务
服务这个概念本身就没有明确的定义，这里定义了组件化的方式，并非是函数或模块或库而是独立的服务。
在文章中首先探讨了微服务与意外模块化设计的本质却别是将服务作为组件来对待的，这样的组件粒度是之前比较少见的。
2.围绕业务组织团队
与传统的前端，后端，数据库的划分不同，微服务主张以业务为划分的依据而非技术
When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval.

这一点得益于技术的发展使得技术本身不再是开发中的最大瓶颈，而以往根据技术来划分团队带来的弊端渐渐超过了其技术优势，这一点是与传统开发模式最大的不同一点。
3.以产品而非项目
where the aim is to deliver some piece of software which is then considered to be completed.
主要是因为对于项目团队和公司没有优化和改进的动力，这样微服务带来的动态设计以及对于扩展的良好支撑则完全发挥不出来。因此在微服务技术初期，微服务是不适合用于项目开发的。
但现在情景已经不同了，基于Spring生态体系构建的SpringCloud等微服务一站式框架的成熟为微服务架构走向项目开发开启了道路。
4.端点更厉害，简化通道Smart endpoints and dumb pipes
这一点主要是与沉重的ESB相互对比的特性。
5.去中心化的管理
这里的管理主要是组织机构的管理，这一点有反应了康威定律。
6.去中心化的数据管理
各个微服务各自管理数据以及业务模型，一切围绕业务
7.基础设施的自动化
用以解决服务增多造成的测试，联调，部署的复杂性问题，这一大块在14年确实是个巨大的痛点，这也是限制微服务项目应用的关键点，但现在各种框架的出现大大减少了这方面的 复杂度，当然对比单体应用要复杂。
8.主动应对故障
这是分布式系统所必然面对的问题，这个不是针对微服务而出现的，实际上故障是分布式系统中最为古老的棘手问题。
9.动态设计
业务是动态的，设计也并非是静止的，动态的设计和扩展性是微服务最大的优势之一。

总结

关键还是看人，
A poor team will always create a poor system - it’s very hard to tell if microservices reduce the mess in this case or make it worse.