博主从事了三年的saas产品开发，这三年的时间都在这一个saas产品上。该产品基本的架构是采取了微服务架构，后段采用java加Spring以及maven，前端使用的是jquery,UI5，数据库则各个模块各自使用自己需要的数据库，主要是postgresql，以及mongodb。中间件则是使用的rabbitmq。部署在aws云平台上面。
后端
后端主要处理项目的核心业务逻辑。后端需要考虑下面这些：
- API versioning即暴露的接口的版本控制。为什么需要考虑这个问题，原因在于我们的接口一旦暴露给客户使用之后，就必须保证接口的稳定性，不能因为升级新功能导致老的接口就无法使用，这样的产品是无法获得用户的好感的。因此，当有新的功能且这个功能需会改变接口的逻辑时，保留当前的接口，而提供一个新版本的接口就是一个很好的办法。例如：老的接口为：api/v1/customer. 新的接口为：api/v2/customer。以此类推，但是需要主要的是，只有当必要的时候才应该去升级版本。
- Authorization访问权限控制->即当调用api时需要提供的用户名和密码。可以考虑vault来进行管理。
- 不同service之间的依赖关系->contract保证
- log日志格式，以及存储位置，以及查看方法。比较常用的日志查看工具有kibana
- 项目用到的构建工具，包管理->maven。对于java项目而言比较常用的还有gradle
- 代码管理->github,使用branch管理代码，要merge代码到master branch需要人进行code review
- 代码质量常见问题，例如code smell，security问题->sonar，vulas等工具
- 代码质量保证->单元测试，集成测试，探索性测试
- 测试覆盖率要求->对于java以及其对应的junit测试框架来说，junit提供了功能可以显示代码的测试覆盖率。其结果用百分比显示，表明代码被测试的覆盖程度。
- 代码format格式风格统一
- 多个instance的时候，负载均衡,服务发现的问题，eruka在这方面可以提供支持。
- 部署问题。部署脚本比较成熟的方案是使用jenkins管理部署的流程。除此之外部署的其他方面也有很多问题。
- 不同service之间的通信问题。直接通信可以采取http call。解耦的通信可以使用message queue.
前端
- UI风格的整体性
- UI文本的翻译支持,以及相关问题->对于全球化产品来说是必要的
- UI的权限访问控制
- session会话管理
- UI和服务器通信的方式
- UI的缓存设计
- UI加载的速度
- UI的代码质量保证，考虑使用checkmarx等静态检测工具
- UI代码的测试问题，单元测试可以考虑Qunit，集成测试可以考虑night watch等工具
整体考虑的问题
- 项目的整体架构设计
- 开发规范定义. 例如对代码命名，风格，测试的统一要求。开发规范最重要的是要保持一致性。
- 项目的开发模式，交付周期，发版方式
- 项目的部署平台，部署流程，如何使用Jenkins 等工具。
- 如何控制项目的新功能上线->feature toggle.使用一个flag，若此flag打开，则新的feature生效，否则不生效。稳定之后则去除相关判断代码。
- scope问题。所谓哦scope指的是一个客户的账户被赋予的权限。不同的权限所看到的内容，做的操作是不一样的。
- 项目的运维，以及客户上线后发现问题的处理
- 项目的功能划分和管理，backlog的管理和实现流程
- 如何监控各个模块的状态,monitor的问题，日志的存储和查看。
- 访问权限设置即权限生命周期管理
- 客户登陆流程
- 项目功能介绍，api文档撰写以及更新
- bug修复规范以及流程，例如可以考虑对每一个发现的bug加一个对应的测试
- 项目的源代码管理. 目前基本都采用Github.
- 前后端校验逻辑的一致性问题-> 在产品开发的过程当中，我们对有的功能的校验可能只会在前端作但是后端却没有做校验。这样可能带来的一个就是我们正常通过UI进行的操作没有问题，错误的请求和不对的数据结构会被挡在外面，但是同样的错误的数据请求直接通过api去访问，则会绕过UI的校验，从而错误的数据会进入数据库。到此还没有结束，这个错误的数据如果不处理，在UI上显示出来则会出现各种无法预料的后果。
- 数据迁移问题->有可能需要考虑
- 法律法规问题,遵守相关信息安全法规，例如GDPR
- 项目各种各样的开发环境配置问题
除了上述之外，采用微服务架构还需要考虑很多微服务本身的问题。这方面可以参考博主其他的关于微服务的博客