我是一个幸运的人！我不是一个好的技术人员，因为我喜欢参与或者说喜欢关心整个项目（或者说产品更加确切）的长期发展。虽然才参加7楼项目才一个星期，并且做的也是相对和业务也是没有多大相关的共通模块。但是通过共通的模块获得一些简单业务或者通过大家传输的思想，让我明白7楼要做产品！
企业应用级别的产品是什么？我个人的理解是企业应用级别的产品其实就是分二个，一个是标准版，一个是定制版本。标准版本其实就是很多业务流程按照行业规范进行处理，一切按照行业规范。而定制产品就是,"老板说什么，业务流程就是什么"。对于定制版本和标准版二个能共用的就是基础应用，例如人事，权限，组织架构等一些最通用的。
PaaS是Platform-as-a-Service的缩写，意思是平台即服务。 把服务器平台作为一种服务提供的商业模式。通过网络进行程序提供的服务称之为SaaS(Software as a Service)，而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。
所谓PaaS实际上是指将软件研发的平台作为一种服务，以SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快SaaS的发展，尤其是加快SaaS应用的开发速度。在2007年国内外SaaS厂商先后推出自己的PaaS平台。
7楼和9楼我不想讨论技术，因为在技术这个领域没有一个正确与错误。其实不管是7楼或者9楼，我们都想做一个可以重用的基础模块，然后对于不同的行业我们有不同的成功案例。在我的认知中，我从来不认为有什么业务完全可以重用，只是需要修改的程度多少而已？然后对于基础模块或者9楼称之为的基础服务这些重用程度才是真正很多产品通用的服务。
对于7楼和9楼最大的相同点是前后台分离和后台作为服务化，但是最大的不同应用定位不同一个产品一个微服务而导致数据库设计这块出现最大的差异性，对于产品而言，我们无需进行分库，而微服务的理念就是每一个产品都是独立的，也就是是说，我每一个服务都必须有一套数据库。这就导致微服务可能会导致数据一致性变弱，而产品，所有的一个业务流程在一个事务中，事务的回滚性变得更加灵活。
相对于7楼，9楼是幸运的，我想偷偷愉快的说9楼的项目进行了三次重构。因为对于一个现场开发的一个项目，并且在时间的要求下，我们必须要快，这就导致我们使用所谓一个"War"解决万能问题(单应用)。但是当我们慢慢实施下去的时候，发现我们没法很愉快的实施下去了，因为客户的需求变更太大了，每次修改的影响范围太大了。
这就导致我们第一次重构，项目组件化，或者说的高大上一点，产品组件化，每一个模块都是一个组件。但是实施出来的还是一个"War"（单应用）.但是对于这个单应用我们是可以进行组合的。对于某一个组件的压力过大的时候，我们号称可以独立部署当前组件，进行分布式。
当项目开发来到南京，朱曦老人家的到来，真正的挑战来了，我们要进行微服务，其实微服务的实施的困难不在于技术的实施，技术总会有解决的时刻，微服务的实施在于每一个服务的设计者对于微服务的理解和服务的设计。本次的重构有着很多的体会。以后有机会慢慢说起吧！
我一直是一个"不安分"的人，我不光光喜欢做一些有挑战的事，我更加喜欢分享会这种东西，因为我知道我只是一个小小的"PG----------"。我需要各种经验分享和经验吸收。就像这次，来到7楼，对我来说其实一个经验，一个对于我而言不一样的经验。不同的平台，不同的实施方案。
分享会议，我个人一直很期待这个，不光光是项目内部的分享会议，而是不同项目的分享会议，因为对于不同的项目，技术方案，肯定有不同吸取的地方，但是我们往往还是处于项目内的“闭门造车”。做了这么多年项目，发现都是一个项目的技术或者什么共通方案沿用到下一项目中，然后会根据这个项目的特殊情况进行修改，我不认为这样的做法有什么不好的，只是这样的引用技术或者方案永远在那几个人心里。
网友评论