关于代码拆分。
目的
优势：
1.解耦合，使得代码更加容易扩展升级。标准版的升级只要不是接口的变化，对其他服务影响为0.
2.领导提出的按图搜房，大量数据的汇总展示。我们维护一个数据源，易于分析，展示。
3.开放出人力成本，一个人可以维护一个或者多个微服务，极大的节约了人力成本。
劣势：
1.对开发要求高，以及重构成本。
思路
1.整体思路。一个基础中心微服务+多个城市特色微服务。
2.基于标准版拆分出多个微服务。每个微服务提供粒子化的对外微服务。
1.首先，登录模块必须独立出来。作为一个独立的微服务，登录模块拆分出来。
思路如下：通过不同url访问前端，前端请求该微服务，服务返回token即可。带着该token访问其他微服务即可。
2.基本工具，基本字典的数据微服务
3.关于不同端的合同发布，备案，本质上是一个service实现的，可能存在部分字段差，这些可以放在一个微服务里面（同理这些具体业务也可以继续拆分为不同的微服务）更加粒子化。可以让备案，房源，做成对外提供服务的基础组件。
4.定时器，这个单独的工程可以直接拆到各个微服务里面，比如很多宽表的同步，个人觉得意义不是很大，可以优化。
3.多个城市特色微服务。一个地方城市就建立一个微服务，其开发工作就是调用基础中心对外的服务的拼装，需要什么就拿什么，就和堆积木一样。如此构成了一个遍布全国的微服务网络。这样服务就可以连起来了。数据也统一起来了。
问题以及解决方案：
1.数据库字段差异：
方案1:中心数据库冗余存储一个字段json类型，可以冗余存储多个字段。
方案2：中心保存最重要的数据，特色城市在维护一个冗余表保存特色字段（存在分布式事务问题）
2.流程差异，比如，特色城市里面是一证多房的问题，就要大改
方案1：基础中心产品评判这个功能是否普遍性较高，若是很高，加入到基础中心微服务里面，反之，特色微服务自己实现一遍，同时把数据也拼装到基础中心（差异太大，没办法，就是相当于重做了，没有的办法）。
3.大量差异很小的工程。
方案1：基础中心设计一个基于配置化的功能，开发在上面点击选择后，可以迅速生成一个简单的脚手架，加速开发，而不是纯粹的复制，减少了大量开发工作。
4.新功能
如若有新的功能，可以由保准化产品定论是否标准化，标准化后再提供微服务调用。
后续新增。每周更新
前端
1.前端同学开发应该是基于antd组件的，可以建议开发一个界面设计器。界面设计器的目的是减少前端的开发量，将html和js分离，界面设计器的概念是我们在界面上配置界面展示如何。然后我们根据配置界面后得到的唯一标识符，只负责编写业务逻辑js代码，可以有效提高前端在新业务上开发的效率。
公有云和私有云
我们可以使用混合云的思路和模式，很多对外城市开发的产品，大多数城市对安全要求很严谨。因此我们不可能将其作为一个微服务放到大的微服务集群里面，因为这是在公有云体系里面，这样安全存在问题，我们必须使用私有云服务体系，将当前这个城市需要的微服务，我们将其提取出来，放到一个私有云里面。然后将其组装为该城市需要的系统，如此既保证了安全的特性，又保证了服务的可用性。
直接复制代码的缺陷
定制化存在这么一个问题，你提供的标准版是稳定的吗？第一可能存在bug,安全漏斗等问题，第二可能存在二次迭代更新，业务定制方也有特色开发，如此造成2个分流的分支，将来如何能合在一起呢？这也是我们公司目前的方案，所以我写了2篇文章来思考新的方案。