微服务实践历程

      微服务概念的出现已经有很多年了，有多少公司在真正使用微服务，今天就把我这几年对微服务的一点感受和大家分享下：

首先，在系统建立之初，有一个问题，到底要不要按照微服务的架构来开始项目？

      这个时候如果我们是接触的一个比较熟悉的行业、熟悉的业务，或者说业务架构师对这一行比较了解，那么可以考虑进行微服务的设计，如果是这个行业的业务比较新，或者本身技术团队对这块业务也在摸索中，那么建议先简化系统的设计，快速的把系统开发出来，先成形再改进。

      其次，微服务的架构本身存在两个方面的架构：技术架构和业务架构；技术架构要考虑高可用、高并发2个特点，目前的解决方案基本成熟，包括spring cloud、dubbo等，都提供了一整套的解决方案，下面我会详细的分享技术方案里面核心的点，掌握了这些核心的点，那么一个微服务技术架构也就没问题了。另外一个业务架构，在系统跑了一年以后就是要重点考虑重构优化的事了，在系统创建之初，从我切身感受，考虑业务架构为时过早，这个时候主要考虑如何将业务流程串联起来，那么当系统跑了一年以后，如何考虑业务架构呢？

    经过一年以上的运行，此时团队的规模逐渐扩大，项目代码也已经很大，团队由最开始的单个团队变成了多个团队。一般情况下，如果公司的业务量没有上去，那么这样的系统也不需要做大的调整，我们这里考虑的是公司的业务量也随之发展起来了。由于之前没有进行专门的业务架构划分，此时各项目组是针对各个子系统级别进行开发的，各个系统都需要进行某块业务的开发，这是单体架构最大的问题就是各系统都开发了，都实现了类似而又不同的代码逻辑，最麻烦的就是数据库层，模块之间没有明确的划分，前期为了快速上线，数据库层也没有经过划分设计，各个表之间相互关联，读写效率问题尤显明显，数据不一致的情况也时有发生。

   那么，问题也找出来了，此时我就要分享下如何去改变这种情况，合适的时候做合适的事，此时做业务架构是最适合的，如果拖延太久，那么便不那么好做了，下面我就来分享如何设计，如何抽丝剥茧。

未完待更。。。