记一次项目开发总结

1，确立项目名称
项目名称：项目区分；
对于一个web应用，最好使用一个contextPath作为其请求接口前缀，原因：在使用微服务模式时，一个真正的服务系统存在多个小的微服务或者公司存在多个项目确需要部署在同一台服务器，
使用contextPath作为前缀可以有效的隔离接口重名所带来的异常，也能在使用同一个反向代理应用时，很好的区分不同微服务；
建议：在确定项目名称的同时，在为项目设定“项目代号”，以便应用系统使用简短的“项目代号”作为前缀进行区分；

2，选择系统架构
应该依据项目用途、项目大小、项目开发周期、硬件与人员资源等情况，确定系统应该使用的架构；
建议：在硬件资源缺少，项目较小，或项目后期无扩展空间等，建议使用单体应用，开发集中，且只需要部署一个应用，可节约硬件资源；

3，微服务开发理解
微服务架构可将系统的多个功能拆分为多个应用，各个应用相对独立，可使用不同开发团队，不同编程语言进行开发，并通过统一的服务管理中心进行管理，可实现服务水平扩展与缩小，且不会影响现有的服务；
优点：
- 服务独立：服务以独立的进程运行，服务的宕机、更新，对整个系统影响很小；应用可依据业务需求动态水平扩展与缩小；
- 服务简单/职责单一：相对单体应用微服务的每一的服务都相对简单，其职责更为单一；
- 开发简单/自由：对于微服务中的每一个服务个体，其开发过程将更加自由与简单，其体现是：可使用不同开发团队，不同编程语言进行开发；
缺点：
- 资源占用：每一个运行的服务，在不设置jvm参数时，一个使用springboot的微服务需要占用至少500m左右的内存；
- 日志不统一：日志记录分散，需要引入额外的应用进行日志管理；
- 管理麻烦：一个很小的微服务系统一般都会有好几个服务模块，并且和几个辅助模块，如使用springcloud开发微服务：一般结构有：1个父项目用于定义和管理微服务使用依赖及其版本，1个服务注册中心，1个服务配置管理服务，1个统一的网关路由服务，
1个或几个公共的依赖服务，几个真正发挥作用的微服务；可以看出，微服务开发时会引入额外的辅助项目，增加服务的管理难度；
- 分布式处理：对于一个业务流程，被分散在几个微服务中时，不能保证该业务的整体流程都能成功执行，所以微服务的开发时需要对同一业务多个服务进行成功或失败处理，这将增加开发难度；