上回说到开心保的系统架构经过几年的演化，由1台服务器扩展到n台，先后引入了Redis缓存、Activemq消息队列、zookeeper、以及dubbo框架，核心模块接口化、集约化，在分布式等去中心化的大趋势下，我们基于降低冗余、减少耦合的实际情况考虑，做了核心服务中心化的决定，现在来看，这一步是正确的，或者是在公司当前的发展阶段这么做是适当的，不但大大降低了开发的成本，也降低了系统风险与复杂度，提升了系统的健壮性。
系统总会演着相似的规律进行演化，这个规律和业务密切相关，特别是在中前期高度契合，而整体上系统的演化是符合正态分布曲线的。
很多时候，当系统响应慢，用户体验变差最有可能的原因是什么？相信很多人首先想到的就是数据库。关系型数据库往往会成为提升系统性能的关键瓶颈，在业务开展初期数据量不大的情况下尚无感觉，随着数据量变大，开发过程中的一些慢sql的影响会指数级放大，是首先需要优化的点，其次才是增加读写分离，提高数据库配置，这几块儿我们同时再做，读写分离是基于阿里的一款产品产品可以根据请求的sql类型决定是路由到主库还是读库，可以使写请求自动转发到主实例，读请求自动转发到各个只读实例。这虽然在程序修改最小化的情况下实现了一定程度上的读写分离，但是也有不少的使用限制，比如事务都会路由到主库，存在非事务读的不一致性等等，所以，对于非事务性的读操作是起作用的，这确实可以缓解主库的压力，但我认为还不是真正意义上的读写分离。欲实现真正的读写分离，需要对系统进行大幅度改造，几乎是外科手术式的，所以这个事对我们来说属于重要但不紧急的。
核心功能接口化可以提升程序复用效率，降低冗余，但同时会增加系统的耦合度，降低系统灵活性，这其实是一种哲学命题，网站的架构应遵循CPA原理，尤其是大型网站，即一个提供数据服务的存储系统无法同时满足数据一致性，数据可用性和伸缩性，三者是三角关系。在系统设计开发过程中，不恰当的迎合各种需求，试图打造一个完美的系统，很容易使设计进入两难境地，后患无穷。唯有三者达到一定的平衡才能形成正三角形，才是最稳固的一种平衡。经过几个月的迭代，根据功能封装了基础数据接口、会员管理接口、营销活动接口、线上支付接口、订单处理接口、购买流程接口以及产品信息接口，因为无论业务渠道如何扩展、市场策略如何转变，最终都会落到这些接口组成的核心流程中，最新的修改也会以最快的速度体现在各渠道的系统，同时也可以看到，这种机制天然的排斥对核心流程进行个性化的定制，显得不够灵活，这也算是一种牺牲吧。
微服务几乎是当前分布式系统架构的标配了，也是实现持续集成、持续交付的保证，微服务架构的风格是通过一个个小型的服务来完成各自独立的应用系统，其中每个小型服务都运行在不同的物理机上或自己独立的进程中，并采用API这种轻量级的方式通信。一般这些服务围绕业务功能来构建，天然具有向全自动部署机制演化的基因。这些微服务甚至可以用不同的语言来编写，使用不同的数据存储机制，我们只需要对这些服务做最低限度的集中管理。所以它是公司向Devops方向转型的必经之路，终极目标是通过更少的投入，更低的成本实现速度更快、质量更高的系统交付。
我们专门成立了一个小组，在对日常需求不产生太大影响的前提下开展微服务相关课题的研究与落地，从框架的评估、工具的甄选到系统的拆分，小组成员在完全没有相关经验的情况下，边学习边实践，最终搭建起了一套由携程开源的Apollo作为配置中心、mybatis作为持久层相配合的基于Eureka服务治理的Spring cloud NetFlix微服务框架，选用Jenkins作为持续集成主体工具，Svn、Junit、Sonarqube、Showdoc分别作为代码版本管理工具、单元测试工具，代码扫描工具和文档管理工具。
由于发布的频率还达不到按需部署、随时发布的程度，主干开发这一自由模式不适合我们的实际情况，因此我们采用的是分支开发的方式，Master Trunk代表最新的发布版本，当需要最新的发布版本，可以直接去trunk的末端，任何类型的branche分支都要求从trunk创建，超过两周未发布的分支都要求定期从trunk合并，减少将来集成时的代码合并冲突问题。每次正式发布以后，需要把发布的内容合并到Trunk里，确保trunk始终代表最新的发布版本。不允许开发者直接往Trunk里提交代码。
基于Trunk的branche通常承载着一个缺陷的修复或者一个需求或分解的任务的开发、测试，完成后会被合并到测试tag进行人工测试，如果测试发现问题就到branche上修复，然后再次合并打包更新修复到测试tag，如果有branche问题太多，必要的话可以放弃它，不影响其它branche的正常流水线作业。不允许开发者直接往测试tag里提交代码。
待测试tag中所有的问题都被修复后，相应的branche就会被合并到预生产tag用于发布，预生产tag是基于trunk最新的，发布以后会把预生产tag合并到trunk里，让trunk代表最新版本。
生产的tag目前暂时未启用，待发布频次大了以后启用。
纵观整个微服务架构改造的，其实最核心的是业务系统的重构，如何切分，切分的边界在哪儿，这是没有现成的道路可循的，只能通过对业务的理解，对系统的整合，在多年形成的错中复杂、盘根错节的相互关系中找到突破口，梳理出一定的脉络，先下手再说，但又要确保这事儿的可持续性和可控性，不能把摊子铺得太大，由外而内，由易向难，循序渐进的去做，切忌急功近利、舍近求远，一味地追求高大上而不顾公司业务和开发团队的实际情况。
最后还是那句话，系统架构的演化能力一部分源自专业的技术和经验，还有一部分源自架构师对业务场景的理解、对人性的把握，甚至对世界的认知。
评论