微服务项目构架让你的插件开发加速
你可能正遭遇这样的境况：你保有多样的插件，还有大批使用那些插件的顾客。除此以外，你还保有大批的产品目录，京东也做得很大且功能强大。一切看上去都较好。
但除了那些，你更要直面许多难题。
你的插件时常崩盘。当它出现难题时，虽然开发者能即刻化解，并且她们复原公交站点的速率也迅速，但这须要牺牲大批时间和心力。想像一下，如果这种无法访问常有，一宕就是三四个半小时，你会经济损失啥的营生？
你的开发者也想化解这个难题，她们有许多想做的事，比如说她们一直想实现一些很酷的新功能。但她们难于完成，即使复原严重错误和紧急搜救耗用了她们太少的心力。
你想雇佣更多的人，但并没有足够多的财政预算支持。而且，你还须要不断招工后辈以代替将要离任的人。比如：雇员Judy去了一间Villamblard的信息技术子公司，雇员Joe返回是即使他在半夜处置了太少的即时状况，深感精疲力竭。
技术难题不仅给你增添阻力，也给你的项目组增添阻力。它让你看不出任何解决之道，把你和你的子公司都赶跑了。
你掉入了一个许多软件子公司和非软件子公司IT部门都掉入过的圈套。那些子公司建立了能处置大部份事的小型的铝制插件。但是那些插件即使显得太过巨大和繁杂，以致于无法控制。没有人能完全了解插件中发生的大部份事。
这时候难题出现了，那些插件须要不断地复原。你尝试添加新的功能或改进现有的功能，但那些更改牵一发而动全身，以致于你无法在短时间内完成那些尝试，而且就算它们完成了，也可能充满了严重错误。因此，你的开发速率显得很慢，而且越来越慢。这时你尝试增加更多的开发者，但她们似乎并没有让事进展得更快，而且新开发者须要花费大批的时间去学习。
这时的你感觉就像被困在泥潭里。
其实困难是能避免的。你不用全盘否定那些插件，而是根据子公司需求重新构建她们。
不断增长的插件
你能先从一个由一个人或一两个小型开发项目组编写和管理的简单插件开始。这个插件如图 1 所示，简洁明了。
图1：一个简单但不断增长的插件
随着时间的推移，插件不断增长。即使插件的成功，导致流量急剧增加，所以你开始添加新的特性和功能，并雇佣更多的开发者来开发插件。迅速，它就看上去像是图 2。
图2：一个繁杂的、停滞不前的插件
现在，新的难题出现了。没人知道她们该负责插件的哪些部分。项目组1做的改变会影响到项目组3。因此，大家的阻力都很大，生产力显得很低，而且严重错误会蔓延到整个插件中。于是你的公交站点开始出现故障，但这时候你可能还以为故障是随机产生的。当出现故障时，您的项目组很难找出难题所在，即使没有人能够了解插件中发生的一切。这就是你遇到的典型困难。
你的独立开发项目组并不是真正独立的，即使一个项目组所做的改变会对其他项目组的工作产生很大的影响。你不能处置独立的项目，即使大部份的项目都是相互交织的。创新被扼杀了，你的业务也是如此。
微服务项目构架的价值
现在一起来看看图3。
图 3：基于微服务项目构架的插件
在微服务项目构架的插件里，每个服务项目都是独立于其他服务项目的。每项服务项目规模都较小，但量Villamblard。每项服务项目之间都有明确的关联，而且也有着明确规范的业务逻辑。
更重要的是，每个服务项目都有单一的负责人，每项服务项目的大部份方面都由一个开发项目组负责。
干净的插件结构会使大部份权和责任更清晰。
简而言之，你的插件得到了扩展。而且，这个扩展不是指它能支持的顾客数量变多了，而是它支持的独立开发者、项目和计划更多了，因此能支持和维护你不断增长的业务。
开发项目组不会互相影响，因此工作效率显得更高。而且，即使低级难题变少，她们会更快乐，有可能在子公司待得更久。
此外，你能通过简单地再平衡大部份权责任来增加开发项目组的数量，从而增加开发者的数量。越来越多的开发者显得更有效率，并且你能在大部份重要的业务项目上取得更好的进展，从而使你的营生发展的更好。
如果出现难题，通过分析服务项目之间的交互，你能更轻松地锁定难题的根源，以及哪个项目组应该负责复原。此外，由于每个项目组的职责范围变小，她们对自己负责的服务项目运作会更清楚，因此能更快、更有效地化解难题。而且，即使她们更了解自己负责的领域，所以也不太可能将严重错误引入系统。
作者 ： Lee Atchison ， 云计算和插件现代化领域公认的 专家 。
