开篇—出一个0到1的微信小程序专栏的初衷

前言

现在市面上太多关于微信小程序的视频及文章，但是大多是做了一些比较概括的讲解，没有真正的带你从无到有去真实的过一遍。基于此小编结合最近自己的开发的一个功能，重新整合部分功能，来带你从0到1完整的实现一个小程序的开发及上线。

思路阐述

思路阐述清楚了，那么我们来说一下加下来的本篇的重点：从0到1搞定一款小程序的一个整体流程：定位、规划以及落地

定位：我们要做一款微信小程序，就一定去了解微信小程序的生态及文档api（后面会带大家去一一了解微信小程序的文档），基于自己的实际业务需求，将我们的功能嵌入到小程序当中。我这里就很明确的定位自己的这款小程序为助手类（工具助手管家）

规划：作为运营开发者往往想把产品做的完美才好，其实不然，只要是产品简单、美观、易用，对用户来说就会有相当不错的体验感。然后在基于产品的规划，慢慢迭代后续功能。

落地：从一个简单地概念及需求的的提炼到最终落地成为一个产品不是那么简单的。真正开发过程中会遇到各种各样的坑，以及不对优化与淘汰，打造出一款简单实用的小程序还是有很多的阻力的。所以，还是那句话，对微信体系的了解，对微信小程序文档的阅读了解，才会对产品的落地有实质的帮助。

业务承载与架构

技术是为人而服务的，工具助手管家中一个很鲜明的特色就是做为人民服务的工具。

小程序他只是个载体，不是为了跟风去做小程序，而是要让小程序成为我们提供服务的一个载体。

挪车码：就是为了实现一个二维码，用户一扫就能够实现号码的拨出，不在用我们手动输入手机号。

后续小程序也会慢慢提供功能迭代。

小程序后台服务端架构，用户量低，我们完全可以采用单体服务架构，随着用户量的增加，我们可以更改为分布式服务架构

图：单体服务架构

 图：分布式服务架构

两种架构的优缺点

单体服务架构与微服务架构在开发、部署方面是有很大的区别的，接下来我们将通过对比两者的优缺点，以及各自适用场景来帮助我们更直观地发现单体服务架构与微服务架构的区别。

　　1.单体服务架构

　　1)优点

　　　　（1)架构结构简单，比较容易理解。

　　　　（2)请求的响应速度较快。

　　　　（3)部署起来相对简单，打包一次即可部署完成

　　2)缺点

　　　　（1)模块与模块之间的耦合度比较高，其中一个模块升级变动，整体都要升级变动。

　　　　（2)开发起来相对来说困难，开发人员之间协调比较困难。

　　　　（3)对于系统的扩展性相对来说比较差。

　　　　（4)分布式部署，相对来说不是那么的零活。

        适用场景：单体服务架构更适用于简单的小型应用程序，对请求响应时间有相对较高的应用以及初创企业资源紧张的初期项目，能够节省服务器资源，减少成本。

　　2.微服务架构

　　1)优点

　　　　（1)项目整体被拆分，降低了整体的耦合度，服务实现自治。

　　　　（2)项目被拆分成多个项目，不同的技术团队负责不同的项目，提高了开发效率。

　　　　（3)技术多样性，可以根据业务来选择相对合适的开发语言、工具进行构建，每个服务可以使用适用于自己的项目的技术，服务之间是互相独立的个体。

　　　　（4)相对来说易于进行扩展。增加某些功能时只是调整自己项目即可，不用调整不相关项目。

　　　　（5)服务间通信机制相互通信

　　　　（6)灵活地进行分布式部署。

　　2)缺点

　　　　（1)系统之间通信。增加接口开发工作量。

　　　　（2)HTTP请求速度慢，可能会有请求速度的影响。

　　　　（3)测试功能相对困难，部署服务相对复杂

        适用场景：适用于业务功能需求比较大而且对项目更新迭代较快的项目

更多编程热点，请点击下方卡片，关注我的公众号《coder练习生》