关于osg μservice和微服务

有些概念---它们不是一些规范标准，所以也没有明确的、具体的实现。因为对概念的理解角度未必一致，我们不能很明确评判一些具体的实现是否在这些概念的范畴之内。

关于服务化架构，就有很多这类的概念，例如：SOA、微服务。

到底什么是SOA？什么是微服务？业界只有一些条目说明，而没有清晰的、硬性的标准和规范。更没有参考实现之类的东西。

于是，不断有不同的实现或架构出来，宣称是SOA,是微服务。按实证主义观点来说，这些都是对的，因为没有标准去证伪，讲得通就行。

虽然当前微服务的概念炒得十分火热，但也不可否认这种多进程构建应用的架构会存在运维的压力，于是DevOps应运而生，试图用自动化运维、多实例部署等手段来解决运维和可靠性问题。

从本质上看，微服务更是为了解决互联网应用性能方面扩展的问题，而非结构方面的问题。可能有人说微服务把大的应用拆分成很多小的领域，分而治之，就解决了结构方面的问题，其实这个是忽略了运维方面的问题，无论应用被拆分得多细，但被拆出来的部分最终还是要组合成完整的应用，只是单体应用基于开发手段来组合，而微服务则基于运维的手段来组合，所以结构问题只是被转移了。

从这点看，单体应用的模块化和微服务在结构上都会有所帮助，避免了意大利面式的代码结构。

微服务架构要求通过独立进程部署达到自治，这是在边界上设定的架构约束，有利于优化领域的边界划分。这点和osgi的classloader隔离有类似的效果，所以osgi应用在设计时，也应该借鉴领域驱动设计的方法。

在服务化方面，osgi服务有动态的特性，这个动态性并非单纯的服务发布和服务下线的动态，还包含服务组装的动态性，这种特性称为Fast forwards。在osgi环境下，我们可以把很多细粒度服务组装成较粗粒度的服务，粗粒度服务依赖细粒度服务的存在而存在，当被依赖的服务下线时，依赖它的服务也立即下线，也就是说只要一个服务发布出来，它就是可用的，不会存在外部可调用，而内部却无能力的情况。

企业应用和互联网应用会有些不同，通常企业应用的结构会更复杂，但性能要求则远低于互联网应用。所以，企业应用不应只强调微服务，而忽视了模块化。

未完待续……