目前对小型项目的讨论非常少。对于大多数创业团队来说，项目初始都不会太大，通常对开发速度和开发成本的要求低于开发质量，加上多数创业团队的技术负责人快速解决具体问题的能力，但并没有良好的架构设计能力。往往在项目庞大到一定程度后，整个项目的可维护性越来越差。我在上一家公司的时候，入职时面对的就是一个典型的不可维护项目，修改任何一处都要耗费数倍于重写的时间，在得知技术负责人不想重写整个项目后，我选择了离职。
对于创业公司来说，存在着这么几个非常棘手的问题：
- 人员素质低。创业团队需要节约钱，于是通常喜欢低于市场价招程序员，甚至在校实习生。这些人员的素质良莠不齐，但总体上说，代码质量堪忧，规范性不懂，骚操作倒是很多。
- 人员流动大。创业团队往往员工成长较快，当薪资跟不上的时候，员工极易离职，甚至一些负责人都会离职。离职后留下的代码其他人往往都不愿意去维护。
- 需求变化快。不要说产品经理的习惯性改需求，就是老板也会时不时的有什么新的主意。为了速度，或者开发人员应付差事，
这些客观问题是存在而且难以解决的，作为小型项目的技术负责人来说，需要利用这些有限的资源，尽量快速高质量的完成各种任务。
我负责的上一个项目完全使用RESTFul风格，每个API URL都对应着一个Resource，由Resource去调用Service（第三方服务）、Model（数据库操作）。但随着项目的增大，Resource的数量越来越多，截至目前，我们内部代号为“LSB”的项目后台代码拥有153个Resource，虽然每个Resource的功能都比较简单，但这么多Resource导致项目越来越难以理解。由于部分需求的反复修改，部分Resource也已经被改的面目全非。
不得不服RESTFul下的横向扩展能力是如此之强，但扩展多了未免感觉像一个庞然大物。
所以决定按照微服务的方式拆分项目。
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端，到后台，数据库访问，数据库都完全是独立的一套。
那么，根据这个标准，我们可以把一个公司的的系统分为以下几个部分：
- 人事管理服务
- 客户管理服务
- 内容发布服务
这三个服务都有自己独立的数据库、后台程序、UI，其中人事管理服务存储了公司所有员工的信息、权限、凭证，为另外两个服务提供RESTFul风格接口。其本身提供的UI可供公司人事部门管理员工，以及员工自己进行修改密码等操作。
RESTFul有四个基本操作：POST、DELETE、PUT、GET，其设计这里不再多说（大家可以看我的文章《REST - 如何抽象为资源（RESOURCE）》），简单设计一下：
- 员工资源
- 增：新增员工
- 删：删除员工
- 改：修改员工资料
- 查：按条件查找员工（开放）
- 员工权限
- 增：为员工授权
- 删：为员工解除授权
- 查：
- 查询员工是否有某项权限（开放）
- 查询员工权限列表
- 权限资源
- 查：查看权限列表
这里使用了类似RBAC的权限模型，不懂的可以略过
这里一个服务只有3个Resource，而且如果公司招的都是有全栈能力的程序员，这个就是一个人的活，非常好追责（额）。
经过按照微服务划分的后，单个微服务开发难度非常低，即使员工能力有限，把这个服务安置按量的开发出来没有什么难度。其内部也非常好理解，即使人员有变动也很好维护。而且拆成这个种程度了，如果真的需求有变化，把这个微服务扔掉重新写代价也不是很大。微服务架构比较好的解决了创业公司在开发小型项目的这个三个痛点。
不过，我感觉以后的业务程序员，不再像是一个技术岗位，而是像一个流水线工人，只有上面把需求设计整理好，听话做出来就好。