Node.js微服务 3 ：从单块软件到微服务

    随着公司的增长，单块软件会有增长的痛苦和低下的效率。

3.1 单块软件

    运行于单一容器且开发周期严格定义的大型软件组件是完全违背敏捷开发原则的：及早交付和频繁交付。

    自然增长指的是，由于缺乏充分的长期规划，在业务压力下，软件系统无计划、无控制地增长。

    控制自然增长的首要任务就是确保公司中的IT部门能与业务部门相匹配。通常大型公司并不将IT部门视为业务核心部门。最终这将导致这些企业没有理想的生态系统来有计划地响应业务需求，只停留在逐个问题、逐个处理的原始阶段。这主要归咎于IT部门的管理者对弈系统的构建几乎一无所知，并且常常忽视软件开发过程中的复杂性。

    幸运的是，由于IT系统已成为世界上99%的业务的驱动者，所以上述情况将有改善的趋势。

    可以将工作内容分成若干个可控的软件工件，并为每个工件对应一个定义好的业务活动，并为它分配一个实体。这个阶段，还不需要将其暴露成微服务，但是，将逻辑保持在一个独立的、定义良好的、易于测试且解耦的模块中，将对我们未来改造应用带来极大的好处。

    解决自然增长的第一步：创建具有良好边界和具有单一职能的细粒度服务，其中单一职能表示将事情做得小而精。

    多抽象才是过度抽象：在没有重复使用3次以上的场景下避免使用抽象。

    Seneca十分符合微服务的设计哲学，通过模式匹配，能够在对已有代码无影响的情况下扩展微服务已有的API：我们的服务对扩展开放，对修改关闭，增加功能的同时不影响已有功能。

3.2 微服务的出现

     以通信服务模块为例，如果开发者继续加入其他通信渠道就进入了失控阶段。这就是单块软件的关键问题所在：限界上下文跨越了多个领域，从而影响到软件的功能性和可维护性这两方面的质量。

module.exports = function(options) {
	var init = {}
	//发送短信
	init.sendSMS = function(destination, content) {
	}
	//读取未读短信列表
	init.readPendingSMS = function () {
	}
	//发送邮件
	init.sendEmail = function(subject, content) {
	}
	//读取邮件列表
	init.readPendingEmails = funciton() {
	}
	//...
	return init;
}

    通过Seneca将它切分成数个小模块emails.js, sms.js

var seneca = require('seneca')()
   .use('email')
   .use('sms')
seneca.listen({port: 1932, host: "10.0.0.7"});

    微服务的缺陷：

   人工操作的开销会使微服务带来的好处大打折扣。

   应用的不一致性

   引入了更多的通信复杂性，这样可能会导致安全问题。

3.3 分割单块软件

    在高访问压力下，邮件发送将会出现延迟，但小型的Seneca模块都是一个高内聚、低耦合的插件，即只需在多台机器上部署邮件服务接口。

    数据才是分割单块软件的主要问题：微服务的主要痛点是缺乏事务性。因此不要过于微服务化，而是对于其他例如邮件、短信和用户注册等辅助模块，则适合微服务化。

    组织架构适配：为了保证构建微服务的敏捷性，每个团队都必须保持自治，这也意味着要确保技术的自主选择权，如使用的语言、代码规范、解决问题的模式等。